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.
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.
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...
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...
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
developer...
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.
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
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
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
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
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
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: