Why JVM5 is slower in Linux than in Windows?
Hi, all:
It really surprised me that Java code runs much faster (at least for not so large
program) in Windows than in Linux.
Recently I tested the speed of part of my learning package, whose task is to
parse a 10MB (about 210,000 lines) text file to extrace some figures ,discretize them and put the
result into a new file.
With the same model of i386 PC (P4 2.8G, 1GB DDR), same version of Sun Java (1.5.0_6), same program (class files compiled by 1.5.0_10), same input data
file, both run from cmd line using default settings (additional option for
java), here is the recorded average execution time
(every time restart the program, not keep running):
OS \t Main \tWhole
Ubuntu5.10: 6s8s
Windows XP: 1.6s2-3s
The 'main' execution time is recorded inside Java program just to evaluate the most
costly part (scan line by line, and parse numbers), so it has removed the
overhead of the startup. The 'whole' time is displayed by 'time' utility. How can the difference be so large? I tried other Linux JRE like IBM and
JRocket with the same code, the result is no better, if not worse.
Is it because different GC strategy setting of
Linux and Windows version or something?
[1291 byte] By [
dislimita] at [2007-11-26 15:26:53]
# 1
I won't guess what it is about Windows that makes perform differently. It could be something like file caching. That's notoriously difficult to measure, but a rough technique is to check the time for running on a newly rebooted system. The fact that the IBM and BEA JVM's behave similarly makes me think it isn't something particular to the Sun JVM.
But if you think it might be a different GC strategy, you could run with -XX:+PrintGCTimeStamps -XX:+PrintGCDetails on both operating systems and see if the collector is running differently. If you can't read the resulting logs to draw your own conclusions, post them both here and I'll take a look at them. From what you've said so far, there shouldn't be any difference in the way the heap is shaped or what collector is used.
# 2
It seems that the critical slow-down reason is that the time logger, namely, System.currentTimeMillis(), which we use to track the internal running time, returns much slower in Linux than in Windows.
If we wipe out the timing, the whole running time in Linux is about 2.5s, even a bit faster than in Windows.
# 3
> It seems that the critical slow-down reason is that
> the time logger, namely, System.currentTimeMillis(),
> which we use to track the internal running time,
> returns much slower in Linux than in Windows.
>
At least at one time on windows that value was cached as part of each application rather than going to the hardware to get the actual time. A timer updated the cached value This was done because it was faster.
This was usually noted when discrepencies were found, because the timer did not keep up the precision of the hardware value.
Other OSes have at times used the same type of functionality.
Perhaps windows still does it and the linux version you are using does not.
