Ridicuouls early optimizations
How many objects in memory are too many so as to justify changing the desing?
Some people think thousands is too much and they start implementing logic in stored procedures and using temporary tables to store results so they minimize the amount of objects they keep in memory.
I had to rewrite from scratch a whole module of a web application just because there was a change in the way a report had to be generated. I decided to make the whole calculation in memory with POJOs. I know I'm extremist :-)
Before the process required:
- A 147 line SQL query that stored a intermediate result in a 20 column table
- 4 stored procedures to do a lot of things in a way it made it impossible to reuse anything.
- A separate stored procedure called elsewhere that precalculated some data.
- The report itself took about a minute to execute or so and required about 100 lines of java code in a struts action.
After the rewrite we have:
- One POJO that does all the calculation (with collaborating with other POJOs, of course).
- It takes 5 seconds.
I think early optimization is evil.
[1155 byte] By [
fedetxfa] at [2007-10-3 0:32:34]
> How many objects in memory are too many so as to
> justify changing the desing?
I do it when I have data that tells me I have too many.
> Some people think thousands is too much and they
> start implementing logic in stored procedures and
> using temporary tables to store results so they
> minimize the amount of objects they keep in memory.
If you've got 2GB of memory, what are 1000s?
It's not just # of objects, it's # of objects per session times the number of simultaneous sessions. Not many sites are used by just one person at a time.
> I had to rewrite from scratch a whole module of a web
> application just because there was a change in the
> way a report had to be generated. I decided to make
> the whole calculation in memory with POJOs. I know
> I'm extremist :-)
>
> Before the process required:
> - A 147 line SQL query that stored a intermediate
> result in a 20 column table
> - 4 stored procedures to do a lot of things in a way
> it made it impossible to reuse anything.
> - A separate stored procedure called elsewhere that
> precalculated some data.
> - The report itself took about a minute to execute or
> so and required about 100 lines of java code in a
> struts action.
>
> After the rewrite we have:
> - One POJO that does all the calculation (with
> collaborating with other POJOs, of course).
> - It takes 5 seconds.
>
> I think early optimization is evil.
Sounds like you did a pretty nice job.
Have you load tested it to see how many simultaneous users you can handle?
%
