Java can be slow or can be very fast; it all depends on the way you code.
The not so recent paper "Java programming for high-performance numerical computing"
explains why, comparing java with Fortran for numeric code (http://www.research.ibm.com/journal/sj/391/moreira.html )
Bottom line : avoid objets, prefer scalars; avoid multidimentional arrays, prefer monodimensional arrays.

Java is certainly great for both computing and GUI interaction, just have a look
at the visualization community (Infovis, etc), most of people often use Java
to develop their tookit, very demanding in terms of GUI performances (sometimes including openGL).

Garbadge collection may be the difficult point to argue; but try Javolution (www.javolution.org) and
you'll get rid of the infamous garbadge collection slowing down process.

A happy java user.

Let's try this again:

1. There are NO appreciable performance differences between programs written in Java and C#, and no practical performance differences with C++ and C.

Java and C# compilers produce meta-code which is subsequently recompiled by their respective runtime engines into machine instructions.

C and C++ (and Fortran and Cobol and Pascal and Algol and ...) compile directly to machine code (earlier compilers often produced assembly code which required post compilation processing).

The modern loaders and optimizers are so good now that there just isn't any performance penalty to speak of.

2. So why do apparently smart people still claim "Java is slow!"???

a. Appearances can be deceiving.

b. Your mileage may vary. Program performance is affected by software design and coding. And Java is purpose built to be machine and OS independent. So Java has an additional abstraction layer between it and the native OS for hardware related functions, most particularly screen output (but also I/O).

We build distributed Java applets and applications for the financial industry that perform MUCH better than our competition -- we can service tens of thousands of nodes across the internet in real-time.

When we started our current business most of our end users had Sun workstations. Now it's almost 100% windows. We haven't had to change a line of code to accomodate the changeover.

Since everyone seems to be focused on the desktop (even though the initial article was broader than that), let me add a couple of comments. I just recently wrote a Java Desktop Application - a MP3 Music Jukebox and Manager. It uses a MySQL database to keep track of potentially 1,000,000+ mp3s, with the ability to easily query the database on a number of categories, and also gives you the ability to write raw SQL if needed. I also use a Java framework I wrote some time ago, which includes logging, event management, background threading, instrumentation, database management including pooling, and a dozen other services. The point of all this, is that through the instrumentation (which can be viewed in a browser since the instrumentation is MBean enabled), I can see ACTUAL performance. Startup time of the app, including rendering, averages about 1.2 seconds (and there are about a hundred Components in the app). Event processing is normally measured in the microseconds (e.g. half or less of a millisecond). I can plow through a 50,000 row MySQL database to retrieve songs in about 300 milliseconds. Having used Windows Media Player, and a number of other Jukebox apps, the Java implementation was no slower, and actually appeared faster. Perhaps some of the people complaining about the performance have not written their code in a manner which provides good performance.

Pardon me, I have been coding since 1973, User interfaces are my cup of tea, Java is a pig when it comes to UI, I'd like to refer to the JVM as the JMV "Java Memory Vortex". To even claim that code compiled and linked as native code code be slower than some bloated runtime engine grinding along just to get a single widget change state, is akin to waxing lyrically about the emperor's new wardrobe. As a language it has it's place and that place excludes the desktop, I'll pitch any old 16 bit p-code up against Java for UI and will beat it hands down..

Nice blog there! Well explained, very informative and most of all you know what you are saying. I didn't know about the purpose of hotspot just till now that I've read your blog!

while I was aware of what you say about JIT compilation and the performance of my Java code vs. my C++ code, I am still faced with benchmarked throughput figures that differ by wide margins (in ESB type middleware code). Is it the overhead of all the J2EE APIs? If so, then it is the path length from my API call to the metal for these functions, not for single instruction execution.

So if I have CPU intensive calculations the difference would be negligible, but if I interact with the outside world I struggle with the layers of code in the VM? This would tie in with Marshall Caro's comment on screen output. But it can't be just that, because my "middleware" examples don't ever write to the screen.

BTW, I think it would be an excellent suggestion to store the compiled "executable" code for later reuse.

Hi Brandon,

It's refreshing to see someone positively linking the words Java and execution speed.

Unfortunately, you've perpetuated the belief that Java desktop applications are inherently inferior. I've heard many a developer tell me that "Java on the desktop is a toy." If you ask these people a few questions, you will find that they use an IDE to code their mission-critical applications. You will also find that their cherished Java IDE is written in, that's correct, Java. So, these developers are using a toy to do their work.

The problem with Java on the desktop is not the JVM. Sun has made many efforts, which you have already identified, to improve performance. The problem is poorly coded Swing applications. The reason those desktop IDEs are so responsive is that they were written by developers who know what they're doing.

The key to creating a responsive Swing application is the proper use of threading in response to user actions. Without using threading, the code executed in response to a user action prevents the underlying graphics code from repainting the screen promptly. The correct approach is to put the code to execute into a runnable instance that will be executed later or concurrently in a separate thread. This allows the method invoked by a user action to return immediately. The Java Tutorial addresses this issue but it doesn't emphasize it in the examples given throughout the tutorial. Inexperienced developers will load up the methods in response to button and menu selections. The result will be an application that appears horribly sluggish and unresponsive.

When talking about most web and business applications, 90% - 95% of the time is spent on non-execution of your code (e.g. database requests, network, file i/o, infrastructure, etc.). So if one language (environment) was even twice as fast as another, so are still talking about only 2.5% - 5% overall. So the better business decision is to write in the language that is easier to develop, maintain and debug.

Actually, there is a large performance gap between C++ applications (and C#) -- vs Java apps. But the difference is in screen output -- Java applications go through a layer of abstraction (AWT) that native (Windows) C++ and C# programs do not.

I agree entirely once the app is running (or applet). However by far the biggest complaint we experience is not performance once an applet is started but the time it takes to start a sizeable applet (1Mb+). We have observed that most of the time is spent starting the JVM itself and then the initial compilation of an applet. It would be great if Sun engineers could work out a way to cache results of previously compiled and optmized applets (even after closing the JVM). Better still if we could get the JVM start-up times much lower.

Thanks.Really great article.Java may seem slow but we shouldn't forget the fact that none of the super fast applications written in C or C++ runs on all platforms without changing their codes.However, Java does this.It runs on all OS platforms like Windows, Linux, Mac.

Great article.Specially I like the last part where you have compared with C++.Thanks