YOUR FEEDBACK
EJM wrote: Well versed article and nice explanation. Easy to understand especially for us w...


2008 East
DIAMOND SPONSOR:
Data Direct
Frontiers in Data Access: The Coming Wave in Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
Intel
Virtualization – Path to Predictive Enterprise
Green Hills
IT Security in a Hostile World
JBoss / freedom oss
Practical SOA Approach
GOLD SPONSORS:
Software AG
The Art & Science of SOA: How Governance Enables Adoption
PlateSpin
Effective Planning for Virtual Infrastructure Growth
Fujitsu
Automated Business Process Discovery & Virtualization Service
Ceedo
Workspace Virtualization
Click For 2007 West
Event Webcasts

2008 East
PLATINUM SPONSORS:
Appcelerator
Think Fast: Accelerate AJAX Development with Appcelerator
GOLD SPONSORS:
DreamFace Interactive
The Ultimate Framework for Creating Personalized Web 2.0 Mashups
ICEsoft
AJAX and Social Computing for the Enterprise
Kaazing
Enterprise Comet: Real–Time, Real–Time, or Real–Time Web 2.0?
Nexaweb
Now Playing: Desktop Apps in the Browser!
Sun
jMaki as an AJAX Mashup Framework
POWER PANELS:
The Business Value
of RIAs
What Lies Beyond AJAX?
KEYNOTES:
Douglas Crockford
Can We Fix the Web?
Anthony Franco
2008: The Year of the RIA
Click For 2007 Event Webcasts
SYS-CON.TV
TOP THREE LINKS YOU MUST CLICK ON


i-Technology Viewpoint: Why Java Is Not Slow
Correcting Logical Fallacies

Not to directly pick on Peter Bell at all (he’s a very smart guy and I really enjoy his blog, so this is nothing personal at all), I just noticed something he mentioned in a recent comment on a blog entry and felt that it was something I should address in a blog post rather than a comment. Also, writing this entry gives me a good reference point later to send to people when they present the same talking point to me.

Anyhow, here is the comment that Peter made which inspired this blog entry (which in context, is a quip):

"I also have to question why you’d even consider using CF for a performance critical app - even Java is a little sluggish. If you want bare metal performance and think your time is worth less than the cost of a server, go for it and write the darn app in C++!"

I wanted to point out and correct a common fallacy that I see repeated over and over again are statements rooted in comments like “If you need speed, you could convert your Java application to C or C++”. I don’t claim to be a Java expert by any means, but I do think I have a good enough understanding of the Java platform as well as basic operating systems and compiler theory and the like to explain why this is a false argument. The answer is actually more along the lines of “it depends on what you are doing”, and I’ll explain why.

It’s very easy to see where this misconception started – pretty much every software developer or system administrator has encountered a slow Swing/AWT based Java application which took forever to start, and generally seemed pretty sluggish. Not to mention it probably looked terrible. One of the best Java based desktop applications, Eclipse, even takes awhile to start. On the contrary, C++ desktop applications typically start very quickly, and are very responsive to user input. Generally speaking the symptoms of running a Java desktop application match the reality– C++ is almost always faster for short running programs such as desktop applications.

Another common assumption is that it would seem that the JVM itself is an abstraction above machine level code because it acts as an interpreter, and that C/C++ will always be faster because the resulting compiled code is “closer to the hardware” which is also false. In the early days of Java, the JVM did in fact interpret code, but eventually it started using a Just In Time compiler in Java 1.2 to compile the code down to the machine level. Different implementations of the JVM use various JIT compilers, but the Sun JVM uses the HotSpot JIT. Not only are Java programs compiled down to machine specific code, but the longer a program runs, the better it gets optimized.

The HotSpot compiler monitors and analyzes an applications performance over time, and uses adaptive optimization to eliminate bottlenecks in the machine code, known as “hotspots”. It essentially looks for pieces of code that are ran time and time again, and marks them for optimization. Those pieces of code are then recompiled again into machine specific code for performance. This allows for ongoing performance enhancements that you would never get from machine code produced by a C or C++ compiler such as branch prediction hints.

All of these things are not just unfounded theory, there have been several independent studies about this including this one by the University of Southern California.

Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled).

This study is several years old now and doesn’t include testing against the many performance enhancements which were made available in the 1.5 JVM, so I’d be interested in seeing an updated study.

That said, Java is probably much faster than you think. One way I’ve seen the Hotspot compiler in action (and you can try at home) is when working on a simple “Hello World” JSP and keeping track of it’s execution time. Typically on the initial run or two, the JSP page is pretty quick, but then after a few calls of the page the Hotspot compiler kicks in and makes it wicked fast so that it’s execution time is effectively nil.

Now that we’ve spoke to the “Java Is Slow” audience, we should cover the answer to the earlier question of “Is Java slower than C/C++?”. This is more of an “it depends” answer. Generally speaking C++ has the advantage in short running applications, and Java is as fast if not faster than C/C++ in long running applications such as servers, web applications, etc. It also might surprise you to know that Java is also very good in real time systems, but that is another blog post of its own.

About Brandon Harper
Brandon Harper has been programming in ColdFusion since 1998 and also actively writes applications in Python and Java. He is currently a Senior Software Developer at Acxiom where he works on an enterprise service platform which powers their risk mitigation products. Brandon was also a technical editor for Inside ColdFusion MX, and maintains a blog at devnulled.com.

YOUR FEEDBACK
semiosys wrote: 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.
Marshall Caro wrote: 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 a...
Ski wrote: 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 Co...
Andre van Westreenen wrote: 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..
James Chua wrote: 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!
Gerd wrote: 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.
Jeff Chapman wrote: 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 applicat...
Ski wrote: 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.
Marshall Caro wrote: 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.
Stu Moss wrote: 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.
ferhad wrote: 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.
dugu wrote: Great article.Specially I like the last part where you have compared with C++.Thanks
LATEST JAVA STORIES & POSTS
Join Scott Guthrie as he discusses Microsoft’s commitment to web standards development, Rich Internet Applications and how Microsoft is contributing to help move the web forward. Join Adobe’s Kevin Lynch as he demonstrates how Flash and HTML come together to make the most eng...
At last year's JavaOne Chris Oliver gave a presentation on JavaFX in which he discussed how he was interested in programming Java2D not in terms of JComponent paintEvent methods that launch into graphics.drawLine(…) or graphics.drawRect(…) code, but instead by allowing the de...
Before describing solutions available for rich client application development, it would be a good idea to explain what exactly a rich client application is and which rich client topologies can feasibly be built using the Java platform. In the main, a rich client is a part of a so...
It's sometimes argued that the Java Community Process's development procedures are secretive and that the general public is excluded from participating. While this may have been the case in the past, it's no longer true. The majority of JCP Expert Groups now do their work in an o...
The one thing that unifies the distributed computing style known as SOA, in most of its manifestations, is self-describing data via the Extensible Markup Language (XML). The benefits of XML over opaque message formats in data interchange are well established. No matter if your fo...
In the past couple of years, interest in Jetty has surged. Jetty is an open source Java-based web and application server and servlet container, but what else do you know about it? To commemorate the 12th anniversary of Jetty, here are 12 things that might surprise you
SUBSCRIBE TO THE WORLD'S MOST POWERFUL NEWSLETTERS
SUBSCRIBE TO OUR RSS FEEDS & GET YOUR SYS-CON NEWS LIVE!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


SYS-CON FEATURED WHITEPAPERS

SPONSORED BY INFRAGISTICS
In every field of design one of the first things students do is learn from the work of others. They ...
There are many forces that influence technological evolution. After a decade of building enterprise ...
2008 is going to be an important year for Rich Internet Applications. Most organizations are deliver...
The OpenAjax Alliance is developing an Ajax industry wishlist for future browsers, using a dedicated...
Infragistics announced the availability of two Community Technology Preview (CTP) User Interface (UI...
The YUI development team has released version 2.5.2; you can download the new release from SourceFor...
ADS BY GOOGLE