Scott Oaks's Blog

Java EE Performance at JavaOne

If you're interested in presenting anything releated to Java EE performance at JavaOne, I encourage you to submit an abstract. We did not have the largest selection of such talks last year, and I'd like to see a lot of performance talks this year.

By the same token, if there are performance-related topics you'd like to hear about at JavaOne, let us know.

I'm vacillating about what I'd like to talk about this year. On the one hand, I'd love people to hear about EJB 3.0 performance and enhancements we've done in grizzly. On the other hand, I've spent so much time this week dispelling performance myths and half-truths that I'm thinking a basic talk about performance may be what's called for.

I remember spending a lot of time 9 years ago dispelling myths about Java performance; in those days, parts of Java were indeed slow. But many other things contributed to performance as well; I remember the article by one Microsoft marketing person talking about an applet he was running, saying that the next step was to wait...and wait...and wait -- because, you see, Java is slow. Of course, he was waiting because he was downloading code over his 14K modem; his issues had nothing to do with Java's performance (even if it wasn't stellar at the time). But that was nine years ago, I remind myself.

So it was depressing to me this week to run into three instances of this sort of thing; apparently we haven't made that much progress in understanding performance. Two of these cases were by developers who ought to have learned better by now (and to be fair, they were willing to), and the third was yet more misanalysis of performance by BEA about SPECjAppServer scores.

The BEA case is of course all about marketing, but it's still depressing to see such misanalysis. In particular, BEA rightly argues that you can't just look at total JOPS and tell anything about a SPECjAppServer 2004 submission, and they further posit that what's important is determining the software and hardware required for your requirements. Exactly so.

Why, then, does BEA next show a calculation of $Hardware/Operations? Didn't they just say that software was an equally important member of the equation? Did they leave out software $ because they didn't want to draw attention to their licensing costs and change the equation out of their favor?

Then, after saying that what's important is $Hardware/Operations, BEA performs a completely different calculation of #CPUS/Operations, as if all CPUs and all systems cost the same amount of money.

Mind-boggling performance analyses like this make me feel that at a fundamental level, performance is still a misunderstood quantity, and rather than talking about the progress we've made, it's time to step back and (re-)learn some fundamentals.

Comments

• What I would like to see are more analyses of interesting real-world problems. The recent discussion in the Mustang forums about parsing text files (http://forums.java.net/jive/thread.jspa?threadID=1933&start=0&tstart=0). The discussion went on and by the end, there was some useful feedback about how to improve the parsing. There are also interesting exchanges popping up on Romain Guy's blog when people write in to suggest performance improvements--interesting to read why those are a good idea--or not.

  Separately, I'd suggest that Sun "declare victory, and retreat", and start having honest and open discussions on where Java performance is not as good as promised. I would prefer to have performance-oriented questions in Java less focused on proving "Java is as fast as C/C++" and more on showing the areas where it really is faster and the areas where it is definitely slower (and especially areas where it will likely remain slower). Let's leave the marketing efforts to the marketers; let's hear about real progress and real *failures* to progress in the last few years. And as for "basic" notes on performance--write them up once, post them on a Sun website, and move on. Holding another talk about them makes me think you are (or must be) avoiding other issues. Cheers! Patrick

  Posted by: pdoubleya on November 15, 2005 at 02:10 AM

This work is licensed under a Creative Commons License.