YOUR FEEDBACK
The 4 Core Principles of Agile Programming
Siegfried wrote: Actually, every elephant has two left feet, and two right...


2007 West
GOLD SPONSORS:
Active Endpoints
Your SOA Needs BPEL for Orchestration
BEA
Virtualized SOA: Adaptive Infrastructure for Demanding Applications
Nexaweb
Overcoming Bandwidth Challenges with Nexaweb
TIBCO
What is Service Virtualization?
SILVER SPONSORS:
WSO2
Using Web Services Technologies and FOSS Solutions
Click For 2007 East
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

Digg This!

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.

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.
read & respond »
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...
read & respond »
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...
read & respond »
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..
read & respond »
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!
read & respond »
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.
read & respond »
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 developer...
read & respond »
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.
read & respond »
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.
read & respond »
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.
read & respond »
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.
read & respond »
dugu wrote: Great article.Specially I like the last part where you have compared with C++.Thanks
read & respond »
LATEST JAVA STORIES & POSTS
Case Study: Java and the Mac
This is the story of a Mac application developer (okay - it's about two of them) who set out on a quest to find an application development tool based on Java so his boss would let him develop on the Mac platform, which he loved. There was only one catch - he had to find a tool th
A Lightweight Approach to SOA and BPM in Java Using jBPM
SOA is mostly associated with technologies such as BPEL, SCA and Web Services. But does SOA really imply these technologies? In this session we will show how you can use the service oriented approach while staying inside the Java world. jBPM is a powerful lightweight framework th
JavaOne 2008: Uncommon Java Bugs
Any large Java source base can have insidious and subtle bugs. Every experienced Java programmer knows that finding and fixing these bugs can be difficult and costly. Fortunately, there are a large number of free open source Java tools available that can be used to find and fix d
The 4 Core Principles of Agile Programming
One of the things I really enjoy at the moment is the recognition and adoption of agile programming as a fully fledged powerful way to deliver quality software projects. As its figurehead is a group of very talented individuals who have created the agile manifesto (http://agilema
JavaOne 2008: Sun Adds Comprehensive Video Capabilities to JavaFX
Sun Microsystems announced it has entered into a multi-year agreement with On2 Technologies to add comprehensive video capabilities, using On2 Technologies TrueMotion video codecs, to Sun's JavaFX, a family of products for creating Rich Internet Applications (RIAs) with immersive
JavaOne Archives - Dvorak Comments on AMD Intel Lawsuit on SYS-CON.TV
Conference in San Francisco. Dvorak held forth on a number of topics, including the new AMD/Intel lawsuit, the viability of Java and Sun, the value of (or lack thereof) of corporate PR, and whether or not a new book about Silicon Valley is really worth reading.
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

ADS BY GOOGLE
BREAKING JAVA NEWS
KongZhong Corporation Reports Unaudited First Quarter 2008 Financial Results
KongZhong Corporation , a leading wireless value-added services (WVAS) and wireless media co