This post originated from an RSS feed registered with Java Buzz
by Weiqi Gao.
Original Post: How Many Milliseconds Ago Was That?
Feed Title: Weiqi Gao's Weblog
Feed URL: http://www.weiqigao.com/blog/rss.xml
Feed Description: Sharing My Experience...
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.
Previous Topic
