Linked by Eugenia Loli on Fri 24th Mar 2006 18:54 UTC, submitted by Jean-Marie Dautelle
Java 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.
Order by: Score:
happy days
by raver31 on Fri 24th Mar 2006 19:06 UTC
raver31
Member since:
2005-07-06

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.

Reply Score: 2

RE: happy days
by Gadget on Fri 24th Mar 2006 21:04 UTC in reply to "happy days"
Gadget Member since:
2005-10-21

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.

Reply Score: 5

RE[2]: happy days
by DoctorPepper on Fri 24th Mar 2006 21:25 UTC in reply to "RE: happy days"
DoctorPepper Member since:
2005-07-12

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.

Reply Score: 1

Angel--Fr@gzill@
Member since:
2005-12-23

!!!
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 ... ;)

!!!

Reply Score: 2

Well at least it becomes faster
by werpu on Fri 24th Mar 2006 20:16 UTC
werpu
Member since:
2006-01-18

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...

Reply Score: 2

Bound to happen...
by EmmEff on Fri 24th Mar 2006 20:18 UTC
EmmEff
Member since:
2005-09-16

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.

Reply Score: 1

Huge performance gain for enterprise!!!
by andyleung on Fri 24th Mar 2006 20:27 UTC
andyleung
Member since:
2006-03-24

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!

Reply Score: 1

someone Member since:
2006-01-12

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.

Reply Score: 1

rondeth Member since:
2005-12-05

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/

Reply Score: 1

AnonaMoose Member since:
2005-08-11

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.

Reply Score: 1

Lumbergh Member since:
2005-06-29

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.

Reply Score: 1

Wow, twice as fast as C code
by snowflake on Fri 24th Mar 2006 20:51 UTC
snowflake
Member since:
2005-07-20

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!

Reply Score: 4

RE: Wow, twice as fast as C code
by someone on Fri 24th Mar 2006 21:20 UTC in reply to "Wow, twice as fast as C code"
someone Member since:
2006-01-12

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

Reply Score: 3

RE: Wow, twice as fast as C code
by unoengborg on Fri 24th Mar 2006 21:31 UTC in reply to "Wow, twice as fast as C code"
unoengborg Member since:
2005-07-06

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.

Reply Score: 5

RE: Wow, twice as fast as C code
by grrr on Fri 24th Mar 2006 23:22 UTC in reply to "Wow, twice as fast as C code"
grrr Member since:
2005-09-03

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.

Reply Score: 1

Benchmarks are for the client JVM
by fornwall on Fri 24th Mar 2006 21:18 UTC
fornwall
Member since:
2006-03-24

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 ;)

Reply Score: 1

BryanFeeney
Member since:
2005-07-06

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...

Reply Score: 2

This is really needed
by riha on Fri 24th Mar 2006 22:45 UTC
riha
Member since:
2006-01-24

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.

Reply Score: 1

It's the Sergey Bubka effect
by malkia on Fri 24th Mar 2006 22:51 UTC
malkia
Member since:
2005-07-17

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.

Reply Score: 2

This is good news!
by Tuishimi on Sat 25th Mar 2006 03:43 UTC
Tuishimi
Member since:
2005-07-06

...unfortunately we won't shift to 1.6 for a year after it is out. ;) Ah well. Our apps will continue to plod along. ;)

Reply Score: 1

New version
by Matzon on Sat 25th Mar 2006 07:29 UTC
Matzon
Member since:
2005-07-06

bah, wuss - we still support 1.1.4 ;)

Reply Score: 1

OT
by dcibils on Sat 25th Mar 2006 17:30 UTC
dcibils
Member since:
2005-12-28

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).

Reply Score: 2

RE: OT
by Emerson on Sat 25th Mar 2006 18:01 UTC in reply to "OT"
Emerson Member since:
2005-09-19

"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.

Reply Score: 1

...
by suryad on Sat 25th Mar 2006 18:06 UTC
suryad
Member since:
2005-07-09

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.

Reply Score: 1

RE: ...
by dsmogor on Sat 25th Mar 2006 20:54 UTC in reply to "..."
dsmogor Member since:
2005-09-01

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

Reply Score: 1

Still crap
by ParanoidAndroid on Sun 26th Mar 2006 10:56 UTC
ParanoidAndroid
Member since:
2006-03-26

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?

Reply Score: 3

RE: Still crap
by Matzon on Sun 26th Mar 2006 22:20 UTC in reply to "Still crap"
Matzon Member since:
2005-07-06

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).

Reply Score: 0