Re: concurrency, threads and objects
Chris Smith wrote:
Tom Forsmo <spam@nospam.net> wrote:
I don't believe in code bloat and I see it as unnecessary runtime
resource consumption. I don't subscribe to the idea that you should not
worry about resources (cpu, memory etc.), because its so cheap. The
reason is simple, bloated code runs slower and is more difficult to
maintain. Think of a program that takes up 300 MB of memory and compare
it to a program that only requires say, 150MB. The smaller program
requires less bus bandwidth between the cpu, memory and disk and less
processing cycles (barring algorithm efficiency).
You seem to see things in black and white. The world doesn't work that
way.
:)
Practically everything is an object in Java. Objects are cheap.
The entire runtime system, memory management, etc. is designed that way,
and people have put lots of effort into making it so. Anything else you
do that tries to minimize creating objects is likely to not be a
noticable improvement, and often hurts the performance of your code.
That only applies if you don't have experience in thinking about
avoiding code bloat and its problems. I have numerous times created
applications that require a fraction of memory or cpu power compared to
a someone's idea that you should not worry about it. In some cases I
have also created working and stable solutions when others have not
managed to get one off the ground, because of code bloat.
Sometimes creating 100 threads
can make your development life easier by helping you separate various
tasks in your application design; but if that cost is okay with you,
Yes, for example in high performance server design, where the server
should be able to handle between thousand and ten thousand transactions
per second.
you
are certainly misplacing your priorities when you worry about creating
that extra 100 objects. This isn't about whether you should be happy
with a sub-optimal program. It's about whether you should worry about
polishing the deck when the Titanic is sinking.
Its funny how many people hide behind that statement, it clearly shows
they really do not know what they are talking about in that respect. I
have experience in thinking about the problem, so I don't use much
"cognitive effort" to avoid it. A person not used to thinking about it
would spend much time worrying about it, which incidentally seems to be
the majority of java developers i have talked to. The mutual feeling
among them seems to be that the JVM will take care of it all for you, so
don't worry your pretty little head about it... I am not saying there
is nothing to what you are saying, of course there is, but its not as
black and white as you are saying it is.
tom