Many Java programs that utilize I/O are excellent candidates for performance tuning. One of the more common problems in Java applications is inefficient I/O. A profile of Java applications and applets that handle significant volumes of data will show significant time spent in I/O routines, implying substantial gains can be had from I/O performance tuning. In fact, the I/O performance issues usually overshadow all other performance issues, making them the first area to concentrate on when tuning performance. Therefore, I/O efficiency should be a high priority for developers looking to optimally increase performance. Unfortunately, optimal reading and writing can be challenging in Java.

Once an application's reliance upon I/O is established and I/O is determined to account for a substantial slice of the applications execution time, performance tuning can be undertaken. The best method for determining the distribution of execution time among methods is to use a profiler. Sunª Javaª WorkShopª software provides an excellent profiler that offers detailed call counts and execution times for each method. System method call statistics can be tabulated as an option. Stream chaining and custom I/O class methods of performance tuning are discussed. An example program is provided that allows the progressive measurement of the progress of the tuning effort. Using the example program that is provided, JavaIOTest.java, and utilizing the techniques described, substantial performance improvements of an order of magnitude can be achieved. Simple stream chaining provides approximately a 91% decrease in execution time from 28,198 milliseconds to 2,510 milliseconds, while a custom BufferedFileReader class cuts performance time by another 75%, over 97% total, to 630 milliseconds for a 250 kilobyte text file on The Sun™ Solaris™ 2.6 operating environment.

Introduction
Java performance is currently a topic of great interest. Performance is usually hotly debated for any relatively new language or operating environment, so this is not surprising. However, Java's reliance upon the availability of sufficient network bandwidth for the downloading of classes shifts the relative benefits of some options for optimization. The reliance on the network penalizes optimization techniques that favor increasing code size in order to provide faster execution. The resulting optimized classes can take longer to download to the client. Of course, server-side Java is not as acutely affected by code size and developers can even consider native code compilers for that case. Based upon anecdotal evidence, most Java development today seems to be concentrated on client-side applets with the result that download times are an important criterion. Java optimization efforts, therefore, need to be well-researched and considered.

Because Java is a relatively new language, optimizing compiler features are less sophisticated than those available for C and C++, leaving room for more "hand-crafting". The "hand" optimization of key sections identified by profilers, such as the profiler available in Sun's Java WorkShop 2.0, can reap substantial benefits.

One of the more common problems in Java applications is inefficient I/O. A profile of Java applications and applets that handle significant volumes of data will show significant time spent in I/O routines, implying substantial gains can be had from I/O performance tuning. In fact, the I/O performance issues usually overshadow all other performance issues, making them the first area to concentrate on when tuning performance. Therefore, I/O efficiency should be a high priority for developers looking to optimally increase performance. Unfortunately, optimal reading and writing can be challenging in Java. Streamlining the use of I/O often results in greater performance gains than all other possible optimizations combined. It is not uncommon to see a speed improvement of at least an order of magnitude using efficient I/O techniques, as this paper and the example program will demonstrate.

This article focuses on the improvement gains possible through careful use of both the existing Java I/O classes and the introduction of a custom file reader, BufferedFileReader. BufferedFileReader is responsible for some of the performance increase of Java WorkShop version 2.0 over version 1.0. An example application is used to read three different file sizes, ranging from 100 kilobytes to 500 kilobytes and the results are compared for various optimizations.

Performance Tuning Through Stream Chaining
As a demonstration of I/O performance tuning, this article will describe the process of tuning a sample program created expressly for this paper: JavaIOTest. JavaIOTest tracks the execution times for several I/O schemes starting with a very basic DataInputStream method and culminating with the use of a custom-buffered, file-reader class, while demonstrating the performance improvements obtained by several program design changes during the tuning effort. The actual execution times are meant to show the relative improvements possible.* The actual execution times will vary widely among the systems used. Readers are cautioned that what is important is the relative improvement on the same system, test-to-test, and that comparisons across operating environments and systems are complex and the results can be specious.

Basic IO: DataInputStream
The I/O method used in this section is a DataInputStream chained to a FileInputStream as shown in Listing 1. This method of reading a file is very common since it is simple, but it is extremely slow. The reason for the poor performance is that the DataInputStream class does no buffering. The resulting reads are done one byte at a time. Several instances of this technique have been found in the JDKª software as well as several "real" Java programs, providing fertile ground for improvement through a tuning regime (see Listing 1).

The results of using the default, basic I/O scheme are as follows. The first section of the example program, JavaIOTest, showed run times of 28,198 milliseconds reading a 250 kilobyte file.*

An Improvement: BufferedInputStream
A simple improvement involves buffering the FileInputStream by interposing a BufferedInputStream in the stream chain. This buffers the data, with the default buffer size of 2048 bytes. Listing 2 illustrates the minor source code change required.

The resulting performance increase for the medium sized file (250 kilobytes) was 91%, from 28,198 milliseconds to 2,510 -- over an order of magnitude with just a simple change.*

The New JDK 1.1 Classes
The foregoing method has provided a substantial performance improvement but has a serious flaw: the readLine() method of DataInputStream does not properly handle Unicode characters. The problem is that the method assumes all characters are one byte in length while Unicode characters are two bytes in length. This method has been deprecated beginning in JDK 1.1. Since deprecated classes are discouraged, the FileReader and BufferedReader classes should be substituted for the classes.

Unfortunately, the scheme to provide for Unicode character localization consists of invoking a locale-dependent converter on the raw bytes to convert them to Java characters, causing an extra copy operation per character. This penalty is offset by other efficiencies in the code. The code change is shown in Listing 3.

The resulting performance increase for the medium file size was 57%, >from 2,510 to 1,092 milliseconds.*

Buffer Size Effects
The buffer size used in buffering schemes is important for performance. As a rule of thumb, bigger is better to a point. In order to examine the impact of the buffer size, a test run was made with a smaller buffer than the default of 8,192 bytes used in the BufferedReader class. Listing 4 shows the code segment using a reduced buffer size of 1,024 bytes.

Depending upon the file's size and platform used for testing, the larger buffer size provided performance improvements ranging from 3 to 13 percent. The use of a large buffer size will improve performance significantly and should be considered unless local memory is restricted.

Summary
Using simple stream-chaining techniques, the execution performance of an I/O bound Java program has been increased an average of 97 percent over using the simple DataInputStream class. This is a substantial improvement for a little extra design work and one that could mean the difference between shipping and re-designing an interactive application.

Tuning with Custom I/O Classes
To this point, tuning has focused on using the core classes distributed with the JDK. With each version of the JDK, more effort seems to be going into tuning critical sections for performance. The improvement in speed of the BufferedReader class over the BufferedInputStream class despite the additional copy per character hints at this. However, if the application needs to read large files, a custom class can be created to further tune performance. The BufferedReader.readLine() method creates an instance of StringBuffer to hold the characters in the line it reads. It then converts the StringBuffer to String, resulting in two more copies per character. The BufferedFileReader class utilizes a modified readLine() method that avoids the extra, double-copy in most cases. It also adds the convenience of creating the FileReader class for the caller. Listing 5 shows the changes required to use this class. The resulting performance increase for the medium file size was 32% overall to 630 milliseconds.*

The BufferedFileReader class is being used in Java WorkShop (package sun.jws.util). The documentation comment in Listing 6 describes the efficiencies added.

Without having to chain together several different classes, as with the standard JDK classes, the example provides a single, efficient class through which a file may be read. It is also more efficient (typically faster) than the fastest JDK classes. Specific optimizations include:
1. More efficiently coded readLine( ) method.
2. Adds open( ) method, so the class can be reused when several files are read in a loop. This avoids repeated allocation and deallocation of buffers.

This class (see Listing 6) contains a self-benchmarking test in its main() method that can be used to measure the exact speedup on a particular system.

Further Tuning
Although the example in Listing 5 is as much as 45 times faster than the example in Listing 1 (and actually comprises fewer lines of code), it is still far from the best that can be done. There are at least two more major optimizations that can be done if still higher performance is required and we are willing to do a little more work.

First, if we look at the first line of the while loop, we see that a new String object is being created for every line of the file being read:

while ((line = in.readLine()) != null) {

This means, for example, that for a 100,000 line file 100,000 String objects would be created. Creating a large number of objects incurs costs in three ways: 1. Time and memory to allocate the space for the objects
2. Time to initialize the objects
3. Time to garbage collect the objects

The problem here is that the I/O buffer is private; the user cannot access it directly. Therefore, BufferedFileReader must create a new String object in order to return the data to the user. Although this follows the conventional assertion that class structures should largely be private in order to control data access, the performance penalty is too high an insurance premium for this case.

To get around this problem, the user must manage the buffer directly without using the BufferedReader or BufferedFileReader convenience classes. This will enable the user to reuse buffers rather than creating a new object each time to hold the data.

Second, strings are inherently less efficient than arrays based upon char. This is because the user must call a method to access each character of a String, whereas the characters can be accessed directly in a char array. Hence, our code example can be made more efficient by avoiding Strings entirely, and using char arrays directly.

Listing 7 shows the code which implements the two optimizations above. It is substantially more lines of code than the previous examples, but tests show it performs as much as 3 times faster than the example in Listing 5.

Performance Tuning Results
The results of running the test program used for this article, JavaIOTest, on text files ranging from 100 kilobytes to 500 kilobytes in size are summarized in the tables found in Appendix One at http://www.sun.com/workshop/java/wp-javaio. The relative performance numbers are more important than the absolute numbers since the system was not isolated nor used exclusively for just the test processes. As the automobile industry states in its disclaimers, "your mileage may vary", readers are again cautioned that what is most important is the relative improvement on the same system and test-to-test. Comparisons across operating environments and systems are complex and the results can be specious.

*Full test results are available at: http://www.sun.com/workshop/java/wp-javaio. See Appendix One.

This article was provided by Engineering, Sun's Authoring and Development Tools Group.