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!

Back to newsletter 082 contents

http://www.fasterj.com/articles/regex1.shtml
Optimising Regular Expression Processing (Page last updated September 2007, Added 2007-09-25, Author Jack Shirazi, Publisher fasterj). Tips:

• Avoid recompiling the regular expression. String class methods wrap the regular expression classes and recompile the regular expression at each method call, so the call should be "unwrapped" if used repeatedly.
• Reuse matcher objects by using the Matcher.reset() method.
• Use indexOf to filter out lines that won't match constant parts of the regular expression, before applying the regular expression (and before creating or resetting the Matcher).
• Instead of using .* at the beginning and end of the pattern, remove those and use Matcher.find().
• The regular expression library can have exponentially bad performance against long lines for some types of matches (one known case is find() with a leading .* failing to match against a long lines).
• There is usually no need to anticipate regular expression performance, it is straightforward to tune (using the tips in the referred article). Use a profiler as normal and if the regular expression is the bottleneck, tune the accordingly.

http://www.developer.com/java/ent/article.php/3680701
Threads Versus The Singleton Pattern (Page last updated May 2007, Added 2007-09-25, Author Rob Lybarger, Publisher developer.com). Tips:

• Modification of a factory class that passes out references to a singleton to instead be thread-saavy is fairly simple using ThreadLocal (assuming the singleton itself is thread-safe).
• It is easy to forget how each request to a singleton may be processed by a separate thread. Making the singleton thread-safe and ThreadLocal makes the requests thread-safe.

http://www.artima.com/weblogs/viewpost.jsp?thread=208018
How Much Concurrency Should be Exposed in a UI Toolkit? (Page last updated June 2007, Added 2007-09-25, Author Frank Sommers, Publisher Artima). Tips:

• Swing's concurrency model is designed such that any change to component state must be performed from the Swing event-handling thread.
• There are convenient means of injecting programmatic action into the Swing event-handling thread, such as SwingWorker and SwingUtilities, now part of the core JDK 6 API.
• A user typing text into a text box is not programmatic access, and is automatically pushed onto the event-handling thread; Reading the values of that text box is programmatic access and, therefore, must be performed by explicitly injecting the reading action into the event-handling thread.
• Creating the UI of a Swing application should not be performed in the main() method's current thread. Instead the developer must explicitly inject the UI-creating statements into the event-handling thread.
• Making the Swing API thread-safe is an impractical option due to the performance penalty this would impose (even apart from other considerations)
• Several third-party APIs make Swing-threading easier, such as Foxtrot and Spin.
• Performing a UI's work in a single thread with the UI blocked for long running operations is not that much of a handicap, in fact it actually matches a user's expectations of many applications - browsers getting a page, word processors loading a document, etc.

http://javaboutique.internet.com/tutorials/multi/
Building Multitasking Applications (Page last updated February 2007, Added 2007-09-25, Author M S Sridhar, Publisher javaboutique). Tips:

• You can make a Java thread have a priority which can range between 1 to 10; threads are created with a default priority of 5 (or that of their parent thread). Priority of 1 is the Thread.MIN_PRIORITY; 10 is the Thread.MAX_PRIORITY.
• A thread can be in one of the following states: Ready: (ready for execution, but not actually being executed); Running: (being executed); Dead: (the run method has completed - it can no longer be executed); Waiting: (to release a monitor, sleeping, etc.).
• The synchronized keyword can restrict the execution of a synchronized block of code to only one thread at a time, as long as each thread is synchronized on the same object.
• Injudicious use of threads can result in memory or stack issues.

http://www.developer.com/java/data/article.php/3680241
Copying Arrays in Java 6 (Page last updated May 2007, Added 2007-09-25, Author Jeff Langr, Publisher developer.com). Tips:

• Sun implemented System.arraycopy to be very fast: It's not implemented in Java, like most of the API, but instead as a native operation that gets executed directly by the JVM.
• In Java 6, there are new overloaded methods, Arrays.copyOf(), Arrays.copyOfRange() that supports a variety of array copying for objects and primitives including copying to different array types (e.g. Double[] target = Arrays.copyOf(new Number[]{ new Double(5.0), new Double(10.0) }, 2, Double[].class);)
• Arrays.copyof is slightly slower than using System.arraycopy, but probably not enough to worry about.

http://www.informit.com/articles/article.aspx?p=1013851
Using Java 2D's Image-Processing Model (Page last updated August 2007, Added 2007-09-25, Author Chet Haase, Romain Guy, Publisher informIT). Tips:

• Filtering an image is as easy as Graphics2D.drawImage(BufferedImage, BufferedImageOp, int, int) - but this can have poor runtime performance.
• An image filter is likely to perform at least a few operations for every pixel in the source image, which easily results in hundreds of thousands, or even millions, of operations on medium or large images. Besides, this method might have to create a temporary image, which takes time and memory.
• For every filter you want to use, you will have to see whether the runtime performance is acceptable or not.
• preprocess an image by doing all the operations offscreen: Image filtered = aBufferedImageOp.filter(anImage, null);
• You can pass a non-null BufferedImage object into BufferedImageOp.filter() as the second parameter to avoid creating a new image on each invocation. Doing so can save performance by reducing costly image creations.
• Using BufferedImage destination = null; for (BufferedImage sourceImage : sourceImagesArray) { destination = op.filter(sourceImage, destination); saveImage(destination);} is optimal for minimizing image creation - and the single created BufferedImage is in a format optimized for the filter, as it is created by the filter itself.
• The Java SE 6 JDK contains five implementations of BufferedImageOp: AffineTransformOp, ColorConvertOp, ConvolveOp, LookupOp, and RescaleOp.
• Avoid using large kernels in a ConvolveOp, as the number of operations applied by the filter is a factor of the number of elements in the kernel multiplied by the number of pixels in the image - a 3x3 kernel performs at least 17 operations (9 multiplications and 8 additions) per color component per pixel.
• Working on a BufferedImage.TYPE_INT_RGB or BufferedImage.TYPE_INT_ARGB results in better performance, since no type conversion is required to store the processed pixels into the destination image.

Jack Shirazi Back to newsletter 082 contents