Java Performance Urban Legends

An anonymous reader writes "Urban legends are kind of like mind viruses; even though we know they are probably not true, we often can't resist the urge to retell them (and thus infect other gullible "hosts") because they make for such good storytelling. Most urban legends have some basis in fact, which only makes them harder to stamp out. Unfortunately, many pointers and tips about Java performance tuning are a lot like urban legends -- someone, somewhere, passes on a "tip" that has (or had) some basis in fact, but through its continued retelling, has lost what truth it once contained. This article examines some of these urban performance legends and sets the record straight."

Comments

Java for Applications....

[NicotineAtNight]

has poor start up time, and requires an absolutely massive amount of memory. That, and garbage collection makes almost-real time ("soft" real time I believe is the technical term) UIs more difficult than they should be.

Also, Swing is a bloated pig.

JNI (native interface) can swap huge numbers of arrays back and forth if you don't test for it and have a fall-back mode.

These are huge pitfalls, even on our multi-GHZ beastly desktops. But they are the only pitfalls.

String requires careful attention.

That's all she wrote folks, I didn't even read the article (should probably post anonymously!) but I've spilled the beans. Nothing else to say.

Re:hmmm

[Anonymous Coward]

Your Errors (1):

• optomizing
• • optimizing

Key:

• error
• • corrected

I only have a Pentium II 266mhz and 32 megs

[zymano]

Yes it sucks to run java but no one uses java applets anymore. The killer app is java server side ecommerce. It's beating Microsoft so we should like it!

Urban Legend? Listen to Sun!

[axxackall]

As already discussed on /. after:
Posted by CmdrTaco on Sunday February 09, @09:46AM
cowmix writes "It turns out that Sun does not eat its own dog food. Specifically, this internal memo from Sun strongly suggests that Java should not be used for Sun's internal projects. More interesting still, they go on to state which other languages fullfil Java's goals better than Java does itself. Finally, the memo states Sun's own Solaris is the cause of many of Java's woes. Yikes."

My favorite pieces to quote:

it appears that the JRE can actually be simpler than the Python RE since Java does at least some of this work at compile time. The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.

While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. This seems to indicate that the resident set requirements of the JRE could be reduced by at least 80%.

Examples include modules that used to be called Swing, RTI, IDL, JSSE and JAAS. These are all good things that should be part of Java. Our concern is that these are not separable modules which can evolve as requirements change. The Java system for evolving the interface (deprecation) does not serve production software very well. Once the interface disappears, the product just breaks.

Production quality programs written in Java, like TogetherJ, indicate a specific Java version which must be installed before the program is run. If another program is installed, requiring a higher Java version, the user may be forced to decide which program stays and which goes away.