Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Performance tests show Java as fast as C++

Java has endured criticism for its laggard performance (relative to C++) since its birth, but the performance gap is closing

By Carmine Mangione, JavaWorld.com, 02/01/98

Page 6 of 7

C++ and Java allocate memory in much the same manner. C++ programs must explicitly release memory back to the system. One major cause of bugs in C++ programs is that programmers forget to explicitly release memory back to the system. This memory is "leaked" and will not be available until the program terminates.

In Java environments, there is a subsystem called a garbage collector that detects when a program no longer needs a piece of memory, and consequently releases it back to the system.

Performance implications: Java versus native C++ (AM)

Since the garbage collector in Java has to be able to determine which pieces of memory are no longer in use, the overhead of memory management for simple tasks is much greater in Java than C++. However, there are two advantages to the Java garbage-collection model that C++ lacks.

First, your programs are virtually immune to memory leaks. Since memory leaks are a frequently occurring bug in large-scale systems, this greatly reduces development time, since you don't have to spend lengthy debugging sessions finding and squashing such leaks.

Second, memory fragmentation can be a major problem in large-scale systems. Memory fragmentation occurs when large numbers of memory allocations are made and released and can seriously hinder the long-term performance of an application. A well-written Java garbage collector can move allocated memory around and prevent fragmentation.

So, although there is an acknowledged trade-off between Java and C++ regarding memory allocation, the trade-off results in great benefits for Java at the price of the performance lost.

One problem with a garbage-collection strategy is that the garbage collector must be able to locate unused objects in memory. If the program tightly adheres to the object-oriented philosophy of containment, the process of garbage collection will be relatively cheap. If, however, the programmer users a procedural approach, it will be difficult for the garbage collector to figure out which objects are not in use due to the complexity of uses relationships.

Real-world example (AM)

Allocating and freeing 10 million 32-bit integers took 0.812 seconds in C++ and 1.592 seconds in Java. This example detects the overhead of the Java allocation system. Even with all of the extra work that the garbage collector has to do, Java's performance in this area is reasonable when compared with C++.

Accessing System Resources (ASR)

In addition to allocating memory, a program requires access to system services such as drawing, sound playing, and window-management routines. Traditional C++ programs access these services through the use of system services APIs. These APIs are unique to each platform forcing the developer to make extensive modifications when porting applications.

Java programs access system services through a single API on all platforms. Each platform contains peer interfaces that map the Java calls to the ones that are available on the platform.

Performance implications: Java versus native C++ (ASR)

In general, the overhead of a call to the system service vastly outweighs the cost of a peer interface in Java. Java programs that use system services perform as well as native C++ programs.