Post a Comment
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!
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/
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.
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...
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.
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).





Ah well. Our apps will continue to plod along.