Reading a recent article on The Java performance debate over there at OSNews, I can't help but notice passages like the following:

This means that by default a Java application won't overwhelm your system and cause heavy swapping and other such nastiness.

People seem to get so focussed on the milliseconds that they forget that if a task takes 0.01s in C++ and 0.02s in Java, then, "oh no", it's half as slow!

Yet, there is no shortage of Java developers who will tell you that Swing is fast.

The biggest trap Swing programmers fall into is that they don't understand the threading model that is employed.

As a Java developer, I will happily sacrifice some memory, and a bit of speed, because ...

In an article aimed at dispelling the dual myth of "Java is slow/Java is a memory hog," they sounded more like excuses than good arguments and advises.

And I contend that this "Can't win, Won't try" attitute is exactly what hurts Java programs and programmers the most. You see, when you subconsciously say to yourself "I'm writing in Java because I want to trade some of that performance off for programming convenience," you are less likely to pay attention to the little things that might have a negative performance impact. And these little things accumulate faster than you think. A dozen milliseconds here, a dozen milliseconds there, pretty soon you are talking about hundreds of milliseconds. And that might be bad for the whole program.

And that brings me to the problem that's bothering me since last week. I wanted measure as accurately as possible the "start up time" of my JVM, when running the "Hello World" program—the elapsed time between the moment the shell forks the Java process and the moment control pass into the main() method.

Any ideas?

Responses[6]

Posted by Weiqi Gao on June 8, 2005 10:35:47 PM CDT #