Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Mustang versus Tiger - Performance comparison.
URL: Javolution Benchmark
At 6:40 PM on Mar 20, 2006, Jean-Marie Dautelle
wrote:
Fresh Jobs for Developers Post a job opportunity
http://javolution.org/doc/results15.txt (Tiger)
http://javolution.org/doc/results16.txt (Mustang)
Here is my (quick) analysis:
- Definitively more agressive/better native compilation in most cases. "Text versus StringBuffer" shows 2x improvement (JDK or Javolution alike). Same for small objects creation (but no changes for large objects creation, still expensive).
- Java serialization/deserialization also 50% faster.
- Unfortunately, java.util.collection results did not improve much! There is definitively room for improvement there (e.g. why ArrayList iterator is about 3x slower than the real-time equivalent FastTable iterator ?).
In summary: Great work at the VM level, but the core library implementation is still far from optimal.
60 replies so far (
Post your own)
Re: Mustang versus Tiger - Performance comparison.
I was wondering when we would get a new chance to read more about Javolution...Anyway, where Java SE 6 will really shine regarding performance will be with Swing. A lot of efforts have been put into Java2D to make the rendering faster. Also now the gray rectangle issue is gone, perceived performance are a blast.
Romain Guy's Java Weblog, #ProgX, Jext
Re: Mustang versus Tiger - Performance comparison.
> - Unfortunately, java.util.collection results did not> improve much! There is definitively room for
> improvement there (e.g. why ArrayList iterator is
> about 3x slower than the real-time equivalent
> FastTable iterator ?).
Perhaps because each collection contains different tradeoffs and tuning options. For example, a quick glance at FastTable's source code I find that "The array sizes are adjusted to ensures that no more than 4 time the required space is ever allocated." . ArrayList won't waste more than 33% of the allocated space (unless you add then remove many elements).
As for iterators, the answer is trivial: ArrayList's iterators are fail-fast (they may throw ConcurrentModificationException), while FastTable's are not. This is a grat safety feature, I'd say almost as important as bounds checking -- concurrent modification bugs are much less common, but when they do happen, much harder to diagnose or even notice if the collection does not flag the problem eagerly and clearly. Of course, in a real-time library there's a different set of tradeoffs, and such feature is a luxury. But it doesn't mean that J2SE's libraries have lots of "room for improvement", at least not in this case.
Re: Mustang versus Tiger - Performance comparison.
> ... This is a grat safety feature, I'd say> almost as important as bounds checking -- concurrent
> modification bugs are much less common, but when they
> do happen, much harder to diagnose or even notice if
> the collection does not flag the problem eagerly and
> clearly...
This raises another interesting question: There are many bound checks and other time-consuming checks in the core library (and Javolution alike). Why not using "assert" for these checks! It seems that "assert" (a 1.4 features) has never been fully exploited, at least not in the core library.
-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: Mustang versus Tiger - Performance comparison.
Jean Marie, have you submitted fixes/patches to solve any of these problems? The mustang site exists for that purpose - if such fixes provably have no downside, they would surely be accepted.NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: Mustang versus Tiger - Performance comparison.
I don't think bound checks qualify as a good use of assertions; assertions are there for things that *can't* go wrong (meaning something is seriously broken - like an OutOfMemoryError caused something to be incorrectly intialized, etc.) - i.e. assertions are for where you're asserting (in the linguistic sense) that the impossible indeed hasn't happened.Bounds errors are common, and if they occur in an app with assertions disabled, they just result in a harder to decipher bug-report. So an IllegalArgumentException is much more appropriate, because the behavior is fail-fast no matter what the VM settings. Using assertions for such things seems like hubris to me - you *won't* get all such bugs out of your code before you ship it and neither will I - we assume otherwise at our peril.
Assertions should be used to test conditions like "the sun isn't shining at midnight", not for things that can result from common programming mistakes - its too easy to have one of those only happen on some boundary condition which you'll never find in testing, and never be able to figure out if you used assertions to check it and then turned them off for the customer sending you the bug report.
The alternative is to expect assertions to be enabled everywhere at runtime. Better to use them for what they were meant for - testing for things that should truly be impossible, not improbable. Not to mention that they are commonly used for sanity checks -
assert new HashSet (List l).size() == l.size()that you really don't want called at runtime in production - some things people do in assertions are not cheap.NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems
Re: Mustang versus Tiger - Performance comparison.
I've noticed that Mustang is much faster with my graphical case tool. I don't know whether the effect is perception or reality -- it just seems a lot faster.Andrew
Re: Mustang versus Tiger - Performance comparison.
RFEs already exist (I submitted several myself) and are still pending! For example the ArrayList unoptimal get(int) has been arround for years (incredibly) and the easy fix provided is still not done in the last beta (ref. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5103956).-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: Mustang versus Tiger - Performance comparison.
> I don't think bound checks qualify as a good use of> assertions; assertions are there for things that
> *can't* go wrong (meaning something is seriously
> broken - like an OutOfMemoryError caused something to
> be incorrectly intialized, etc.) -
I don't agree, RuntimeException and assertion serve the same purpose (finding programming errors).
I happen to think that penalizing all Java applications out there to facilitate the debugging of poorly tested code is a bad idea
> Assertions should be used to test conditions like
> "the sun isn't shining at midnight", not for things
> that can result from common programming mistakes -
If it is the case, no wonder that nobody use assert (who want to test for the impossible).
-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: Mustang versus Tiger - Performance comparison.
Then you should really look up for the definition of an assertion.Romain Guy's Java Weblog, #ProgX, Jext
Re: Mustang versus Tiger - Performance comparison.
Good analysis, I just voted in this bug. Some comments:The addition of pre-checks before calling out-of-line methods that generate the exception is ugly, because you break encapsulation of these checks. They are repeated at all call sites, which affects maintenability etc. I'm sure that some engineer at Sun will say that such code dirtiness should be avoided and we should rely on the JIT compiler to perform an equivalent optimization, if not today, perhaps in a future release. BUT I think these methods like get() are sufficiently critical to deserve any amount of hacking to deliver maximum performance. Put some huge comments yelling that any changes to RangeCheck() should be propagated manually to all call sites, and get over it.
The second impression is that the true problem is over-design. I never liked Java's decison of having several kinds of range-check exceptions: IndexOutOfBounds, ArrayIndexOutOfBounds, StringIndexOutOfBounds... of course the specific exceptions will provide more detailed error messages(*), but exceptions thrown manually are very costly, while the automatic exceptions are lighter because they are generated by the JIT compiler, that knows dozens of tricks to optimize reduce their cost (loop versioning, etc.). But then, it's too late to debate this design, which is cast forever in the stone of API compatibility.
(*) I would only justify manually-thrown exceptions in the rare cases where the index wouldn't be reported correctly, e.g. in a circular array where, at some point in time, get(10) fetches element 78 from an internal array because the head is positioned at 68. But these cases are rare, and they could use the same exception type.
Der Ton macht die Musik
is a popular saying in Germany (see Title).It means:
It's not what you say, but how you say it
"This is pretty amazingly bad code. " (Well it isn't concerning the age of the code)
"I shudder to think about how poorly the rest of the code has been written with regard to efficiency."
Give those guys a break, will ya? The code was perfectly fine at the time of writing.
Re: Der Ton macht die Musik
I agree. Whoever wrote this RFE might be right; but this kind of comments did not help his cause...-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: Mustang versus Tiger - Performance comparison.
I've been working on an application for 4 years now and its been in production for 3. The application has become huge and far bigger than any one developer fit in his or her head. But its also mature, so we don't get many new bugs in the system - we fixed 95% of them ages ago.But when we do get a bug, on average it takes us two weeks to locate the cause of the bug and five minutes to actually fix it. We had one bug that took us 6 months of on and off testing to locate and 1 minute to fix. The reason for this is simple: most bugs in Java programs document their cause making fixing them very easy. In very mature apps you've fixed these bugs the moment you saw the incriminating stack trace and all you're left with are the extremely obscure and difficult to reproduce bugs.
Fixing these types of bugs is soul destroying. However, whe we do get a genuine ArrayIndexOutOfBoundsException or even a ConcurrentModificationException, real genuine tears of joy roll down our collective cheeks because 90% of the time the cause of these bugs is written in the stack trace.
If you ever find yourself not fully appreciating Java's transparent fail-fast behaviour, I suggest a Java sabbatical into the land of C programming. One of our C teams spent 4 months hunting an array overflow bug that only occured in production and never in test. How much would a fail-fast stack trace have been worth to them? (No new project are allowed to be written in C/C++ now).
Brendon
Re: Mustang versus Tiger - Performance comparison.
> RFEs already exist (I submitted several myself) and> are still pending! For example the ArrayList
I said patches/fixes, not RFEs, for a reason. I'm not saying "if you want it fixed, go fix it yourself", BUT - if I really want something fixed in any project I depend on - if I *really* want it fixed, I write a patch and submit it (I can point out examples, but it would get boring fast). If I do that, I've dramatically increased the probability that it will get fixed in the timeframe I prefer, because I've just made someone's life easier for them, and that's probably a person with more demands on their time and attention than only mine. I'm not saying someone shouldn't randomly step up to the plate and fix these things, nor am I saying it's your obligation to - just that my experience is that, well, this is software, and to fix something somebody has to do the work, and the best way I can guarantee something happen is if I simply do the work, whether that's supposed to be my job or not in a perfect world.
NetBeans.org
Evangelist/Senior Staff Engineer, Sun Microsystems