Extrinsic Performance Issues
Performance Considerations
Performance Considerations
  Contents

PDF version   PostScript version

Intrinsic Performance Issues

Java is a simple, object-oriented, portable, strongly-typed and boundary-safe language--with a built-in automated garbage collection mechanism. These features clearly result in a higher programmer productivity--of around 40-50% compared to C++ according to (Prechelt, 2000). On the other hand, (IBM Research, 2000) suggests that the associated performance loss is in the order of 20%.
Whereas the latter figure is probably acceptable for most business application code (e.g. EJBs, servlets), it may not be the same for system-level code (e.g. JVMs, application servers). In this case, the critical section of the code may be optimised by pooling/recycling objects, using custom data-structures,...up to rewriting some of the code in C and integrating it via the Java Native Interface (JNI).

A consideration which importance is often underestimated is the choice of a Java Virtual Machine (JVM). Although this behaviour has obviously changed in the past few years, the JVMs from Sun Microsystems where mainly targeted at client applications. An example of this was the implementation of an asynchronous garbage-collector (Hunt & McManus, 1998); allowing the user threads to be suspended while garbage-collection was taking place. With the migration of Java to a server-side programming language, the situation has much improved. In particular, the old adage ``Java is slow because interpreted'' is now almost irrelevant, with the adoption of technologies such as Just In Time (JIT) compilation and Sun's HotSpot Server. The Java vendor TowerJ now sells a high-performance, server-side-only JVM.

We use in this project an IBM virtual machine (IBM Java 2, 1.3 for Linux) since it is the best performing free JVM for Linux, according to the Volano benchmark (the reference benchmark for JVMs).