The first benchmark of Mustang (JDK1.6) versus Tiger (JDK1.5) shows that Java users are up for an agreeable surprise. According to this JavaLobby discussion the virtual machine raw speed has improved significantly (40-100%). Although, the core library implementation (e.g. collections) could also benefit from some rework/optimizations.
Mustang (1.6) Vs Tiger (1.5) Java Virtual Machine Comparison
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This will be great for the enterprise.
At long last Seibel and Oracle Helpdesk 2 will be able to keep up with our CSR’s.
This will be great for the enterprise.
I didn’t know NCC-1701 ran Java. If that’s so, maybe that’s why Warf always had such a scowl on his face.
Of course it did! That’s why the Enterprise computers had to use FTL (faster than light) processors in their cores! 😉
Actually, I don’t find Java that slow anyway. I do a lot of desktop development (Swing) in Java, and it works great for me.
!!!
Good to know java is improving in speed… cause sometimes it pi** me off, in my PCs…
Well, if we believe SUN and Java lovers, in 2 years it will finish being quicker than C, or assambler …
!!!
every release, I know a software of a certain Washington based corporation which becomes half as fast with every new release… and thus copes well with the doubling of processor speeds in about the same timeframe…
This was bound to happen and I’m glad that it has.
As the code gets more mature and more eyes are laid upon it, certain optimizations previously not discovered or even considered by Sun developers are able to be made.
Imagine how many Collection objects are being used for Web<–>EJB<–>DB? This even benefits the most simple architecture, so it would be nice to have it. Think about clustering with tons of 4U w/ 16GB monsters loaded with tons of Collection objects from DB querying? omg, good job Sun!
I believe Javolution is designed as a drop-in replacement for much of the Collection Framework and a few other commonly used classes (ie. String). However, it would still be nice if Sun could improve upon its implementation of the Collection Framework.
Hello! Regarding (specifically) Java Collection performance, you may wish to look into Trove (if you haven’t already). They’re not “drop in” replacements, but they offer faster/optimized versions of the standard Collection types as well.
http://www.onjava.com/pub/a/onjava/2002/06/12/trove.html
http://trove4j.sourceforge.net/
Howdy
If we finally had some decent auto boxing/unboxing then trove wouldn`t be needed, things like this should be a compiler responsibility not a programers.
No dice. It’s (as you probably know) just a compiler trick. .NET will still spank it hard. They’ve got escape analysis in it now though which probably accounts for some of the speedups.
Since we’re continually being told that java now runs as fast as a C coded app, I can’t wait to run the new Java which according to the figures will be twice as fast raw C. Java GUI apps will leave tradiational Windows GUI applications in the dust!
Actually, I am still waiting for Sun to implement JIT caching. This feature is essential for the client version of JVM. Without it, they are very limited in the kind of JIT optimizations they can do, since many optimizations take too long and users open and exit applications very frequently on the desktop.
JIT caching will bring native startup time and better than native performance (due to the possibility of very aggressive optimizations from the JIT) to the desktop.
Edited 2006-03-24 21:23
Not necessarily, C compilers get better over time as well. However, java can do one thing that C so far can’t and that is contiously optimizing running code. So at least in theory java cuold be faster than C.
The subjective speed of an application also have a lot to do with responsiveness. Responsiveness is actually something else than execution speed. E.g. a if a java application have to load large chunks of class librararies when it starts, and a native windows app can take advantages of allready loaded DLLs, the C application will likely appear faster even if the code in C and java executed at the same speed.
Another factor in the experienced speed is what feed back you are give the user. E.g. when starting an applicationf you can show the user that something actually is going on by throwing up a progress bar. If you can do that quickly your users will have a much higher acceptance for waiting. In C, you can show this progressbar much faster due to the fact that it might allready is preloaded.
I think it was c++ code and that was probably the server hotspot jit and this is about the client hotspot jit but i think it was probebly stil not true.
Remember that the mentioned speedups are for the client JVM, which has been much more improved (relatively speaking) in mustang than the server one.
That considered, this is great news
In particular, it can delegate to GTK for themes for which it has no built in support. In this screenshot, NetBeans 5 is running on a system using the unsupported QtCurve theme, and it fits in pretty well:
http://www.bfeeney.uklinux.net/images/netbeans5-java6.png
As for the benchmarks, I think a lot of them were in the server JVM for a while, but Sun has definitely been doing some work on the client-side too. Unfortunately, while escape analysis has gone in (speeding things up in some cases), stack allocation has been deferred to Dolphin, so the performance benefits won’t be as good as originally hoped.
More on that is here:
http://forums.java.net/jive/thread.jspa?threadID=2664&messageID=779…
Because Java sucks on macosX for example, and if it can be speed up on that platform and be as fast as in windows or linux, it would be great.
The Sergey Bubka effect. “Ukrainian pole vaulter Sergey Bubka earned $50,000 every time he set a new world record. From 1983 to 1998 he set world records 35 times… never by more than a quarter of an inch.” Internet research.
…unfortunately we won’t shift to 1.6 for a year after it is out.
Ah well. Our apps will continue to plod along. 
bah, wuss – we still support 1.1.4
Kind of off topic, but is there any benchmark showing a good mono vs. msft.net vs. java VMs like this one ?
How does collections or strings manipulation perform compared to the other VMs ?
I’ve did some c# on mono and it’s really snappy, feels faster than java for me (I’m a java coder).
“Kind of off topic, but is there any benchmark showing a good mono vs. msft.net vs. java VMs like this one ?”
The url seems to have slipped my mind, and more importantly, my bookmarks. But I know there is at least one good site that keeps fairly up to date with benchmarking compilers and VMs.
From my own playing around, the Java 6 builds from about three months back came out significantly ahead of mono in almost everything I threw at them. Mono did tend to fare pretty well against gcj compiled java though.
Java 6 seems to be shaping up quite nice and these are all beta builds! Besides the performance advantage I am ooking forward to the GroupLayout being included in the final release because Matisse is so much faster to use to create GUIs and I hate the idea of having to bundle the additional layout as a separate jar. I hope they integrate it finally. And for those who like to live on the bleeding edge, you guys should check out the java 6 build from java.net instead of what sun is hosting as a beta because that beta is really really old.
You will have to bundle it anyway for years to come as new JRE adoption is not instant.
If it will have the same interface as the one you use now, you will encounter additional problems on 1.6
For years I’ve heard java developers say java is getting faster and faster. A few years ago they claimed it was almost as fast as binary C code. Java will never be as fast as compiled C/C++ code, assembler, etc. This is logical since there is some overhead from the virtual machine.
But how do you explain all the performance boosts (over 200% in the last few years according to java developers) when it was already as fast as C?
Please think before you write.
Java can continue to improve speed becase it has the benefit of a VM that can dynamically re/compile code as it goes along. C/C++ is AOT (Ahead of Time) compiled and can therefore not do runtime optimizations.
Lots of code is faster in Java than AOT compiled C – however for general purpose code Java is probably slower (though productivity gains easily outweight this in most cases).