Back to newsletter 035 contents

http://www.JavaPerformanceTuning.com/news/roundup034.shtml
Kirk's Roundup September 2003 (Page last updated September 2003, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• use ?verbosegc to tell you if garbage collection is interfering with your benchmark.
• Workload can be quantified as the number of concurrent users, the type of work that they do, and how often they perform work; resulting in the number of requests processed.
• Synchronized code in Windows can run slower on a multi-processor machine than on a single cpu machine.
• The ?server flag on MacOS JVM may be ignored.
• There is little difference between using a local variable and using a field if hotspot inlines the field.

http://www.JavaPerformanceTuning.com/news/roundup033.shtml
Kirk's Roundup August 2003 (Page last updated August 2003, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• The overhead of serialization and de-serialization can render external caching ineffective compared to internal caching.
• Running multiple JVMs may be better or worse than running one JVM depending on the efficiency of the garbage collection.
• JRockit appears to have a low cost dynamically configured performance monitor.

http://www.JavaPerformanceTuning.com/news/roundup032.shtml
Kirk's Roundup July 2003 (Page last updated July 2003, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• For parsing strings custom parsing using String is fastest, StringTokenizer is 40% slower and String.split() 140% slower.
• To most efficiently determine the number of rows in a database when you are also going to subsequently process those rows, use "SELECT count(*)" for large tables, or rs.last();int numOfRowsRetrieved = rs.getRow();rs.beforeFirst() with CachedRowSet or a ResultSet which caches rows for small tables.
• OutputStream.write() behavior is not sufficiently specified to determine if it blocks. Consequently OutputStream.write() can block
• OutputStream.write() is only likely to block for a significant length of time in the case where a slow connection was flooded with data, such as a dialup line.
• There is no way of guaranteeing non-blocking writes with OutputStream.write(). You need to use NIO writes for non-blocking behavior.
• OutputStream.write() could give an exception rather than blocking, and you need to be able to handle this in high volume writes. (And note that the exception thrown when the OS buffer is overrun is a NullPointerException, and not a type of IOException).
• The Java Collections classes can easily produce and discard lots of new objects, which can be a liability in tight loops.
• Type-specific collection classes are recommended for optimal performance (collection classes which directly hold primitive data types rather than having to wrap those data types).
• Skip ahead lists have shortcuts to specific elements in order to make traversal faster by "skipping ahead" to elements
• Parallel arrays can let you convert arrays of objects to arrays of primitives.
• Getting the data structure right goes a huge way to solving any particular problem, including performance problems.
• If you are not reusing statements, there is no benefit to PreparedStatements.
• For best effect you need to be able to reuse PrepareStatements across connections, and only some drivers support this.

http://www.JavaPerformanceTuning.com/news/roundup031.shtml
Kirk's Roundup June 2003 (Page last updated June 2003, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• Calling System.gc() can slow down the system by forcing the garbage collector to run when it would not need to. This is sufficiently performance draining that the latest JVMs have a flag which, when set, tells the JVM to completely ignore calls to System.gc().
• JDO is layered on top of JDBC so it cannot be faster than pure JDBC. However it may be faster to develop object relational mappings using the JDO, and as long as performance is adequate, good design wins.
• Thread.sleep() only changes the state of a thread to runnable once the sleep time has run out; that doesn't mean that the thread will run at that instant.

http://www.JavaPerformanceTuning.com/news/roundup030.shtml
Kirk's Roundup May 2003 (Page last updated May 2003, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• NIO enables the replacement of multiple blocking threads with one multiplexing thread.
• When using NIO select, Only register modes (e.g. READ, WRITE) that you want handle immediately; all unwritten sockets are read for writing so registering interest in WRITE mode would return from select immediately.
• ColorModels are optimized on each platform, and you should use the default ColorModel, from GraphicsConfiguration.getColorModel(), or Toolkit.getColorModel() to gain the optimal cross-platform performance.
• Running a batch job simplistically, as if each record manipulation was like one user call, would be like simulating millions of user requests, causing millions of very short transactions and would likely bring a system (especially database) to its knees. Handle batches by throttling the requests, combining transactions and controlling when commits occur.

http://www.JavaPerformanceTuning.com/news/roundup029.shtml
Kirk's Roundup April 2003 (Page last updated April 2003, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• Microbenchmarks can be easily skewed by the timings when HotSpot optimizations occur and when GC occurs.
• Referring to a concrete impementation class rather than an interface can make changing the implementation used much more difficult in a tuning phase.
• To scale an existing architecture: determine where the bottleneck exists by running a stress test; then try to load balance the system so that the capacity of the constrained resource can be enlarged.
• The constrained resource in many systems is the database. Moving the database to it?s own piece of hardware is the one solution which often helps.
• Messaging systems throughput are limited by both the size of their payloads and the rate of requests.

http://www.JavaPerformanceTuning.com/news/roundup028.shtml
Kirk's Roundup March 2003 (Page last updated March 2003, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• Static methods are marginally faster than non-static methods (but it is bad design to use statics for object behavior).
• It is more efficient to use direct-to-database bulk loading rather than using EJBs to indirectly bulk load a database.

http://www.JavaPerformanceTuning.com/news/roundup027.shtml
Kirk's Roundup February 2003 (Page last updated February 2003, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• MappedBuffer can utilize significant memory resources from a machine, and may be less efficient than reading a file into JVM memory.
• EJB Local interfaces are faster than remote interfaces even when communication is in the same JVM because they avoid marshalling overheads.
• Reusing objects from a static pool can still have a significant edge over creation & GC of objects for some kinds of applications.
• In 1.4.1 ThreadLocal is much faster and Thread.currentThread() is now so fast it's nearly free.

http://www.JavaPerformanceTuning.com/news/roundup026.shtml
Kirk's Roundup January 2003 (Page last updated January 2003, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• The XML classes delivered with 1.4.1 may not have optimal performance compared to the xalan package.
• Make it work, make it right, and make it fast by profiling.
• RMI has a much better performance profile than SOAP, but is not cross-language capable as SOAP is.
• EJBs have a high performance overhead when they are not needed. Read-only objects is one such case.

http://www.JavaPerformanceTuning.com/news/roundup025.shtml
Kirk's Roundup December 2002 (Page last updated December 2002, Added 2003-10-31, Author Kirk Pepperdine, Publisher JavaPerformanceTuining.com). Tips:

• To compare elements in very large files it may be necessary to sort them and compare them a fragment at a time, possibly using an external index structure to maintain a sorted order.
• For tile drawing the BLT call is expensive bit, not the size of the tiles.
• Background buffers BLT'd to screen using offsets are the way to handle changes in perspective
• VolatileImage is essential for efficient drawing (though not yet fully effective on Linux and not fully supportive of transparent images, in 1.4.x).
• To draw scaled images the fastest you may need to enable some forms of hardware scaling: specify -Dsun.java2d.ddscale=true.
• -Dsun.java2d.trace=log helps to see what 2D primitives are being used.
• Image.getScaledInstance() has some major performance issues; you should get an image with Component.createImage() or GraphicsConfiguraton.createCompatibleImage(), and use one of the Graphics.drawImage() calls (which scale on-the-fly) to render your source image to the new image.
• Good CMP performance requires: no statefull session beans; pooled session beans; no lazy reads; stored procedures for extreme cases; free your entity and session beans, mybean = null; an efficient DB driver.
• Try every JVM you have access to with your application, they will all produce different performance, and one will be the overall fastest for your application.

Jack Shirazi

Back to newsletter 035 contents