Re: concurrency, threads and objects



Chris Smith wrote:
Tom Forsmo <spam@xxxxxxxxxx> 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
.

Relevant Pages

  • Re: cent os 4.5 with 16 gigs of ram
    ... available memory. ... this is NOT anything to worry about. ... kernel and I have 2 gigs free, so the above memory usage doesn't seem ... I'm assuming kernel-hugemem.i686 is compatible with more than one cpu. ...
    (alt.os.linux)
  • Re: Email Attachments
    ... I am concerned about bottlenecks both in our internet pipe, memory and CPU ... on the server. ... Is there a worry that this will bring my mail system to a stand still? ...
    (microsoft.public.exchange.admin)
  • Next July 27: boot failure(hang) on x86_64 box.
    ... Freeing unused kernel memory: 1360k freed ... ACPI: PM-Timer IO Port: 0x488 ... CPU: L2 Cache: 1024K ... # AX.25 network device drivers ...
    (Linux-Kernel)
  • [PATCH] Document Linuxs memory barriers [try #3]
    ... The attached patch documents the Linux kernel's memory barriers. ... I've tried to get rid of the concept of memory accesses appearing on the bus; ... barring implicit enforcement by the CPU. ...
    (Linux-Kernel)
  • Oops in 2.6.28-rc9 and -rc8 -- mtrr issues / e1000e
    ... Bios 1.04beta did show correct memory sizing in dmidecode, ... I hope this is as simple as me doing something glaringly wrong in the kernel ... DMI present. ... CPU: L2 cache: 6144K ...
    (Linux-Kernel)