Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

Newsletter no. 12, November 27th, 2001

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC 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

Get rid of your performance problems and memory leaks!

I have often found myself creating collection classes for holding primitive data types (like int) for performance purposes. The advantages of avoiding the primitive wrapper classes (e.g. Integer) and the attendant extra objects, method accesses and casts can be significant. So I was delighted to hear from Eric Friedman who is building a free open source library dedicated to implementing performance optimized collection classes, including collections which directly support primitive data types. The project, called Trove, is hosted on sourceforge at

The usual mixture of articles is missing this month. For the first time in a while we don't have a games or embedded performance article. But one on SOAP has appeared, and the enterprise Java articles (atomic file transactions, RMI) are increasingly sophisticated.

Kirk continues his airport performance analysis, as well as his usual succint coverage of the performance discussion groups.

And here's my usual reminder to our Japanese readers that Yukio Andoh's translation should be available at in a while.


Java performance tuning related news.



Recent Articles

All the following page references have their tips extracted below.

Older Pages

All the following page references have their tips extracted below.

Jack Shirazi

Kirk's roundup

Last month, I commented upon my travel through airports. Since then, there has been a dramatic increase in the amount of security in place at airports. There has also been about a 20% reduction in the number of flights as fewer people are flying. How have these changes affected my travel time? Since we are looking at a reduction in the amount of traffic, one would think that we should see an overall reduction in my travel time. My experiences so far run counter to that assumption. To see why, let's divide the system of air travel into three parts; travel from airport entrance to my seat on the aircraft, travel on the aircraft, and travel from aircraft door to the airport exit.

The time it takes for me to get from the aircraft door until I exit the airport has not changed. Due to reduced air traffic, there has been an expected improvement in on-time performance. But, that reduction only applies to flights that were late. So, the overall benefit has been negligible. The biggest impact on my travel time has been the amount of time that it takes me to pass through the airport to the aircraft. So, let's break down that portion of the system so that we might better understand what is happening.

The biggest change has been the introduction of extra security. This can be seen at check-in, the x-ray and metal detector screening and during the boarding process, three points of serialization in this portion of the system. Interestingly enough, the effect of the extra security check introduced during the check-in and boarding process is negligible. During check-in, the extra security is carried out as the counter agent is waiting for other tasks to complete and thus does not result in an increase in service time. The extra check during the boarding process does add to the service time but since the true bottleneck is people trying to stuff oversized carry on bags into the undersized overhead, this time is not noticeable. The biggest effect comes in the serialization point where the increase in service time cannot be hidden, the x-ray/metal detector screening. The effect of service time on throughput can be explored using the formula T = 1 / S, where T is the throughput, and S is the service time. For example, if it normally took about 10 seconds to pass through the metal detector, T = 1 / 10 sec which yields 360 passenger per hour. It now takes about 20 seconds. So, T = 1 / 20 sec which yields 180 passengers per hour. More complex statistics can be used to predict my expected time in the queue but the overall effect is that I need to get to the airport earlier.

The JavaRanch

This month did see an increase in the number of discussions in the saloon at the Java Ranch. What started out as a discussion on whether initializing object references improved performance turned into an interesting discussion on garbage collection and local variable storage. The original question was quickly answered. By default, objects are initialized to null. Performing this initialization twice is a performance drain. More interestingly, it was pointed out that even though local variables are declared on the stack, the data is maintained in the heap. The consequence of this is that all local variables will be garbage collected when the stack frame goes out of scope.

Another discussion centered on an application that took a significant amount of time to process a ResultSet from a JDBC call. The JDBC call was returning several tens of thousands of records from the database. The most interesting point drawn out during the discussion was the fact that some JDBC drivers will return a ResultSet as soon as some data is available. This may lead to a situation where the subsequent next() calls will block. This gives the appearance that the query ran quickly but processing the results was the problem. So, things are not always as they seem.

A greenhorn asked a question on how best to reuse a StringBuffer. When toString() is called on a StringBuffer, it passes the underlying char array to the String. Any subsequent changes to the StringBuffer will force it to create a new char array. Since you cannot control how the array is created, it is most likely better just to create a new StringBuffer. Reading the source code for StringBuffer turned out to be invaluable for answering this question.

The Server Side

What are the effects of the serialization points that exist in the systems you work with? ECPerf is an Enterprise JavaBean benchmark being developed under the Java Community Process (JCP). Its purpose is to measure the scalability and performance of J2EE servers. It does not focus on presentation or DBMS scalability. In addition to what can be found at, The Middleware Company lists several resources at pertaining to ECPerf. You can also find additional sources at

A participant was looking for tools to help with his performance testing. Most of the respondents represented vendors. The following is a list of their offerings.

You can find reviews at

As is typically the case, the gamers are at the bleeding edge of technology in their quest to provide us with the best gaming experience possible. Such was the case with a question regarding the class GatheringByteChannel and buffer classes found in the nio package in the new jdk1.4. The answer describes a very important difference between direct and nondirect buffer object. Simply put, direct buffer objects are directly read from and written to channels. Reads and writes performed on nondirect buffer objects cause data to be copied. Consequently, nondirect buffers are slower and may generate garbage. The advice: you should convert nondirect buffers to direct buffers if you will be using them more than once.

Timers are used by games to control the frame rates on the display. Thus they are critical to the look of a game. Further evidence of how bleeding edge gamers really are is the thread on timers. The thread starts out complaining about the lack of a high-resolution reliable timer. The following code fragment was offered as a solution but, the problems were quickly pointed out and some corrections were offered.

while(true) { 
        synchronized(this) { 
    } catch ( InterruptedException e ) { } 

The first problem was that sleep time could not always be counted upon. For instance, sleep(4) == sleep(0) and sleep(5) == sleep(10). Though this difference may look small, if you?re doing timing related activities, you may experience a significant amount of drift. This lengthy thread pointed out many other pitfalls and offered many other great recommendations.

Kirk Pepperdine.

The RandomAccess interface. (Page last updated October 2001, Added 2001-11-27, Author Jack Shirazi). Tips:
Converting booleans to strings. (Page last updated November 2001, Added 2001-11-27, Author Tony Sintes). Tips:
Atomic File Transactions. (Page last updated November 2001, Added 2001-11-27, Author Jonathan Amsterdam). Tips:
Double-checked locking revisited. (Page last updated November 2001, Added 2001-11-27, Author Brian Goetz). Tips:
Command objects for RMI. (Page last updated October 2001, Added 2001-11-27, Author William Grosso). Tips:
Caching RMI stubs. (Page last updated October 2001, Added 2001-11-27, Author William Grosso). Tips:
Website performance. (Page last updated October 2001, Added 2001-11-27, Author Gordon Benett). Tips:
Scaling SOAP-based web services. (Page last updated November 2001, Added 2001-11-27, Author Frank Cohen). Tips:
Chapter 1, "What Is Performance?" of "Java Platform Performance". (Page last updated 2000, Added 2001-11-27, Author Steve Wilson and Jeff Kesselman). Tips:
Chapter 2, "The Performance Process" of "Java Platform Performance". (Page last updated 2000, Added 2001-11-27, Author Steve Wilson and Jeff Kesselman). Tips:
Chapter 3, "Measurement Is Everything" of "Java Platform Performance". (Page last updated 2000, Added 2001-11-27, Author Steve Wilson and Jeff Kesselman). Tips:

Jack Shirazi

Last Updated: 2024-03-29
Copyright © 2000-2024 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us