JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

This month we have a nice crop of JDBC tuning articles; more on J2EE performance and scalability; a couple of articles on optimizing embedded Java; and several articles delving into core Java including SoftMaps and Enumerations. The animation/games focused article this month comes from Java3D, listing tips from the J3D mailing list; and in the news section there is an interesting article from a C++ games programmer who has converted to Java.

In addition there is one more article that I found particularly fascinating, as it is the first article I have seen which addresses audio performance ("Writing a seamless audio looper").

Kirk covers the interesting discussions over the last month, and adds his view on the prospects for the latest incarnation of GemStone. And finally here's my usual reminder to our Japanese readers that Yukio Andoh's translation should be available at http://www.hatena.org/JavaPerformanceTuning/ in a while.

News

Java performance tuning related news.

• I've added a new section to the resources page, Java to native code compilers.
• C++ games programmer converted to pure Java makes his case.
• Measuring the data abstraction penalty of small Java objects.
• Sun community chat on Java 1.4, giving an updated situation
• Excelsior Java-to-Windows native code compiler improves performance (compared to previous versions of their compiler).
• Java Specification Request to enhance the BigDecimal class primarily to efficiently support floating point arithmetic.
• Second update of proposed 1.4 SDK contents. Search the doc for "fast" to find performance enhancements.
• Our unknown app server is faster than some other carefully selected app servers, using a benchmark that we give no details about.

Recent Articles

All the following page references have their tips extracted below.

• Writing a seamless audio looper (Earthweb)
  
• Optimizing JDBC (JavaDevelopersJournal)
  
• Optimizing JDBC Prepared Statments (TheServerSide). Also a followup discussion at http://www.theserverside.com/discussion/thread.jsp?thread_id=8013
  
• Connection Pooling with JRun (Allaire)
  
• EJB2.0 Container-Managed Persistence (Sun)
  
• J2EE clustering (JavaWorld)
  
• Caching (JavaWorld)
  
• SoftReference-based HashMap (Java Zone)
  
• Performance tuning embedded Java (OnJava)
  
• Java 3D performance tips (J3D/Sun)
  
• BigDecimal and Enumerations (Sun)
  
• Flicker-free graphics with the Mobile Information Device Profile (Sun)
  

Links

• Another short list. Why don't they all just point to me?

Tools

• I've added a new section to the resources page, Java to native code compilers, with several previously unlisted compilers.

Jack Shirazi

Kirk's roundup

As the dot bombs continue to super-nova, in addition to the many people being jettisoned, some interesting technologies are also being dumped. Such was the case with Brokat Technologies (BROA) when they sold their Blaze Soft and GemStone divisions for 20M USD and 1.7M USD respectively. It?s been about one year since Brokat exchanged 550M USD in stock for Blaze and 250M USD in stock for GemStone. GemStone has a twenty-year history building application servers. Their first large commercial offering was a very scalable Smalltalk application server (GSS). In October of 1997, GemStone offered the first version of their Java application server, GSJ. Since GSJ shares the same fundamental architecture as GSS, it is arguably, the oldest piece of Java technology on the planet.

While BEA was pouring on the marketing and pushing WebLogic to support the latest and greatest spec, GSJ lagged behind. Brokat decided to release an EJB 1.1 compliant GSJ and put its GemStone division into maintenance mode. The version was never even released. At 1.7M USD, buying GemStone should be a safe bet. The J2EE/EJB server market is just coming to understand the scalability issue, GemStone?s sweet spot. This makes it the right time to re-energize GemStone.

[editorial note: Kirk had been intimately involved with GemStone for many years until recently. Given the established scalability of the product, many of us were sad to see the company being slowly dismantled by Brokat, so hopefully new ownership will give GemStone a new lease of life.

For those of you interested in the financials: the 250M USD of Brokat shares used to acquire GemStone has a current share value of about 5M-10M USD. When Brokat acquired GemStone it was profitable, with at least 20M USD turnover.]

The JavaRanch

If you take a walk to the saloon at the Java Ranch (www.javaranch.com), you?ll find the usual array of regulars mixing it up with the latest batch of greenhorns. This months offering includes an interesting question on the import statement. The question: does using the wild card * have any impact on performance? The answer is no (at least not for runtime performance). Well, then, why bother to explicitly import classes? That question leads me to two of my other favorite topics, readability and metrics. Programming languages were written for human readability. Explicitly importing classes allows me to quickly determine what a class is using. One metric that I rely upon during a tuning exercise is the level of coupling in the code. From experience, I know, the higher the level of coupling, the more fun I?m going to have after I?ve made some changes. Looking at the number of import statements in a class helps to understand just how much fun I?m going to have. Using * makes it much more difficult to eyeball this metric. When I?m coding, if I see a certain depth of import statements, then I start asking the question, is this class doing too much. As a final point, using * does add a little (very little) extra performance overhead during the compilation phase (import is a compiler directive, not a runtime bytecode).

One of the ranch hands ran 4 applications in the same VM and noted a 60% overall reduction in memory usage. He was curious as to why this might be. The answer is that all of the applications were sharing many of the same classes, and much of the JVM overhead. Many application severs use this technique to allow deployed applications to share common classes. You need to code with care as the Class.forName("MyClass") can cause ClassNotFoundException to be thrown. I recommend always using Class.forName("MyClass", true, Thread.currentThread().getContextClassLoader()) as this will allow classes loaded in a parent class loader to see classes loaded by it?s children.

JavaGaming.org

This months Java Gaming (www.javagaming.org) offered one very interesting question. How many of the published Java performance tuning tips are still valid given the recent improvements VM technology. The recent addition of generational garbage collection certainly has changed the picture on object creation and pooling. In my opinion, object pooling has dubious benefit. Recent advances in VM technology should eventually eliminate the need for this level of hack. Most predominantly is the advent of generational garbage collection. The thread provides an excellent description of how this all works. The best advice given was to use a profiler to determine if object pooling was really providing you with enough of a benefit to justify the complexity and cost.

In addition, the C++ comparison question (troll?) migrated to JavaGaming. This led to a spirited discussion, which seems to have adjusted the opinion of the original poster that pure Java was now sufficient for writing games (as reflected in his article).

Finally, outside the performance forum, Niels J?rgensen describes how using a DirectColorModel with no alpha channel (new DirectColorModel(32,0x00ff0000,0x0000ff00,0x000000ff)) along with MemoryImageSource.newPixels(), speeded up image drawing considerably compared to using the default color model. The thread ( JavaGaming.Org Message Board: 2D Graphics Programming in Java: AWT: Oddities of drawImage() ) covered some more detail on how to use newPixels().

The Server Side

For my last discussion group, lets check out the Middleware Company at www.theserverside.com. There was an interesting thread regarding JDBC connection pooling. A participant reported that Allaire is making recommendations not to use connection pooling in some situations. The argument reportedly made by Allaire, is that enterprise DBs already pool the connections on the DB, which is more efficient. The problem with this claim is that a connection has two ends. Another reader correctly pointed out that Allaire?s claim was not to use their connection pooling when using a JDBC 2.0 compliant driver (see the article on Connection Pooling with JRun listed in the tips section of this issue).

Another thread asked about EJB performance vs. JDBC direct calls. This question must appear more times in more lists than just about any other. It would be safe to say that EJB performance can be, at most, no better than using direct calls and, at worst, considerably slower. The reasoning? In both cases, you?re storing data in an object to a relational DB using the same SQL. Using EJB architecture places a framework between you and the data you want to store. Hence, there is an added cost to using an EJB. But, the industry considers EJB technology to be good enough to cover the cost. In many applications, the benefits of using EJBs does outweigh the performance cost.

And finally, a story was related to me. A consultant was asked how fast his company?s middleware would go. The consultant responded with, "how fast does your bicycle go?". [time to get out the CPU hand-cranker - ed.]

Kirk Pepperdine.

Tips

http://developer.java.sun.com/developer/technicalArticles/ebeans/EJB20CMP/
EJB2.0 Container-Managed Persistence (Page last updated July 2001, Added 2001-08-20, Author Beth Stearns). Tips:

• EJB 2.0 Container-Managed Persistence provides local interfaces which can avoid the performance overheads of remote interfaces.

http://www.sys-con.com/java/article.cfm?id=725
Optimizing JDBC (Page last updated August 2001, Added 2001-08-20, Author John Goodson). Tips:

• Minimize the use of Metadata: Cache all metadata as they will not change; Avoid using null arguments in metadata methods; Use a dummy query with getMetadata() rather than getColumns().
• Retrieve data as efficiently as possible: Minimize the amount of data returned by the query; Don't make average users pay the same query cost of the users with extensive query requirements; Remember that users seldom want to see too much data in one go; Use setMaxRows(), setMaxFieldSize(), and SetFetchSize(); Decrease the column size; Use the smallest packet size that will meet your needs (if the driver supports packate sizing).
• Use a parametrized remote procedure call (RPC) rather than passing parameters as part of the RPC call, e.g. use Connection.prepareCall("Call getCustName (?)").setLong (1,12345) rather than Connection.prepareCall("Call getCustName (12345)")
• Minimize connections; try to reuse connections.
• Turn autocommit off.
• Avoid using distributed transactions.
• Use getBestRowIndentifier() to determine the optimal set of columns to use in the Where clause for updating data. (The columns returned could be pseudo-columns that can provide pointers to the exact location of the data, and are not obtained by getColumns().)

http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-extremescale2.html
J2EE clustering (Page last updated August 2001, Added 2001-08-20, Author Abraham Kang). Tips:

• Consider cluster-related and load balancing programming issues from the beginning of the development process.
• Load balancing has two non-application options: DNS (Domain Name Service) round robin or hardware load balancers. [Article discusses the pros and cons].
• To support distributed sessions, make sure: all session referenced objects are serializable; store session state changes in a central repository.
• Try to keep multiple copies of objects to a minimum.

http://www.java-zone.com/free/articles/Kabutz01/Kabutz01-1.asp
SoftReference-based HashMap (Page last updated August 2001, Added 2001-08-20, Author Heinz Kabutz). Tips:

• WeakHashMaps are not ideal if you want the values to be weakly referenced rather than the keys.
• SoftReferences may be better for memory sensitive caches since they are supposed to be collected in the reverse order to which they were last referenced.
• Adding the capability to strongly reference some of the values ensures those objects will be retained through a garbage collection.

http://softwaredev.earthweb.com/java/article/0,,12082_862481,00.html
Writing a seamless audio looper (Page last updated August 2001, Added 2001-08-20, Author Greg Travis). Tips:

• Switching audio streams from one piece of sound to another requires some fiddly managing of the transition delay in order to avoid a gap in the audio output.
• To avoid the transition delay, you need to: flush the output buffer; find out how much data was dumped; add a fudge factor; and combine these values to determine from where to start playing the new audio stream.

http://www.onjava.com/pub/a/onjava/synd/2001/08/15/embedded.html
Performance tuning embedded Java (Page last updated August 2001, Added 2001-08-20, Author Vincent Perrier). Tips:

• All the following affect embedded Java performance: hardware processor selection; (real-time) operating system selection; supported Java APIs; application reliability and scalability; graphics support; and the ability to put the application code into ROM.
• Various approaches for boosting bytecode execution speed include: a JIT compiler (usually too big for embedded systems); an ahead-of-time compiler (requires more ROM, may disallow or slowdown dynamically loaded classes); a dynamic adaptive compiler (half-way house between last two options); putting the Java application code into ROM; rewriting the JVM interpretation loop in assembly; using a Java hardware accelerator.
• Use the lightweight graphical toolkit.
• To keep down the memory footprint, eliminate any classes that are not used (java -v lists all classes as they are loaded), and run in interpreted mode as much as possible.
• Benchmark results are not necessarily applicable to your application [article reviews the applicability of standard and proprietary benchmarks].

http://www.j3d.org/tutorials/quick_fix/perf_guide_1_1.html
Java 3D performance tips (Page last updated June 2001, Added 2001-08-20, Author Doug Twilleager). Tips:

• Once an application calls BranchGroup.compile() or SharedGroup.compile(), only objects with their capability bits set can be modified.
• Use capability bits to describe which objects change at runtime, so that J3D can optimize the app. Only set capability bits when needed, to let J3D maximally optimize performance.
• Set the bounds of objects so that J3D can ignore objects outside target object spatial scopes.
• Reorder leaf nodes for the most efficient rendering.
• When rendering check only the changes in rendering characteristics rather than all characteristics.
• Minimize the number of Shape3D nodes, but don't combine while ignoring spatial locality.
• Use the stripifier, or manually stripify the application: try to convert the geometry into long strips of triangles rather than fans of triangles.
• Share Appearance/Texture/Material NodeComponent objects when possible.
• Set the thread priorities appropriately, or use the default priority. Minimize thread activity.
• Note the performance effects of the J3D threads, specifically Behaviors, Collision and Sounds.
• J3D fully supports multi-processor machines. Use native threads where possible.
• Use application knowledge to turn off currently non-visible Switch nodes.
• Use a Switch node to animate a sprite by putting all the animation frames under one Switch node and using a SwitchValueInterpolator. This increases memory consumption in favor of smooth animations.
• Unordered groups are faster than ordered groups.
• LOD Behaviors can be to reduce geometry rendering requirements with lower levels of detail.
• Use bounds based picking rather than geometry based picking.
• Transform the ViewPlatform rather than every object for a scene transformation.

http://www.theserverside.com/resources/article.jsp?l=Prepared-Statments
Optimizing JDBC Prepared Statments. Also a followup discussion at http://www.theserverside.com/discussion/thread.jsp?thread_id=8013 (Page last updated July 2001, Added 2001-08-20, Author ?). Tips:

• Databases analyze query statements to decide how to process them most optimally, then cache the resulting query plan, keyed on the full statement. Reusing identical statements reuses the query plan.
• Alering the statement causes a new query plan to be generated for each new statement. However statements with parameters can have the query plan reused, so use parameters rather than regenerating the statement with different values.
• Using a new connection requires a prepared statement to be recreated. Reusing connections allows a prepared statement to be reused.
• Connection pools should have associated PreparedStatement caches so that the PreparedStatements are automatically reused.

http://www.allaire.com/Handlers/index.cfm?ID=17266&Method=Full&Cache=Off
Connection Pooling with JRun (Page last updated June 2001, Added 2001-08-20, Author Karl Moss). Tips:

• Establishing an initial connection is one of the most expensive database operations. Use a pool of connections that are ready and waiting for use to minimize the connection overhead.
• Connection pooling is one of the largest performance improvements available for applications which are database intensive.
• Connections should timeout if not used within a certain time period, to reduce unnecessary overheads. Initial and maximum pool sizes provide further mechanisms for fine-tuning the pool.
• JDBC 2.0 supports connection pooling, though a particular driver may or may not use the support. If pooling is supported by the driver, it is probably more efficient than a proprietary pooling mechanism since it can leverage database specific features.

http://www.javaworld.com/javaworld/jw-07-2001/jw-0720-cache.html
Caching (Page last updated July 2001, Added 2001-08-20, Author Jonathan Lurie). Tips:

• Nice description of caching using a filing system analogy.
• Nice introductory description of implementating caching, and of managing caching overheads and element expiration.

http://developer.java.sun.com/developer/JDCTechTips/2001/tt0807.html
BigDecimal and Enumerations (Page last updated August 2001, Added 2001-08-20, Author Glen McCluskey). Tips:

• BigDecimal provides arbitrary-precision floating point number arithmetic, at the cost of performance.
• Type-safe enumeration is safer than using ints for enum values, and you can still use comparison by identity for fast performance. But you lose the performance potential of using the enum values directly as array indices, switch constants and bitmasks.

http://developer.java.sun.com/developer/J2METechTips/2001/tt0725.html
Flicker-free graphics with the Mobile Information Device Profile (Page last updated July 2001, Added 2001-08-20, Author Eric Giguere). Tips:

• Use double buffering: draw into an offscreen buffer, then copy into the display buffer. Copying buffers is very fast on most devices, while directly drawing to a display sometimes causes users to see a flicker, as individual parts of the display are updated. Double buffering avoids flickering by combining multiple individual drawing operations into a single copy operation.
• Use the Canvas.isDoubleBuffered() method, to determine if double buffering is already automatically used: on some implementations the Canvas object's paint method is already a Graphics object of an offscreen buffer managed by the system. (The system then takes care of copying the offscreen buffer to the display.)
• Use javax.microedition.lcdui.Image class to create an offscreen memory buffer, and use Graphics to draw to the offscreen buffer and to copy the contents of the offscreen buffer onto the display. The offscreen buffer is created by calling one of the Image.createImage methods.
• Double buffering does have some overhead: if only making small changes to the display, it might be slower to use double buffering.
• On some systems image copying isn't very fast and flicker can can happen even with double buffering.
• Keep the number of offscreen buffers to a minimum. There is a memory penalty to pay for double buffering: the offscreen memory buffer can consume a large amount of memory.
• Free the offscreen buffer whenever the canvas is hidden (use the canvas' hideNotify() and showNotify() methods.)

Jack Shirazi