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 088 contents

http://www.fasterj.com/articles/deephouseinterview.shtml
Interviewing Dan Diephouse (Page last updated March 2008, Added 2008-03-30, Author Kirk Pepperdine, Publisher Fasterj.com). Tips:

• Applications that require the last microsecond of performance should not use XML for communications. But otherwise XML conversions can be done in a millisecond and so are not a problem for the vast majority of applications.
• Loading the whole XML into memory using the DOM model is usually unnecessary and often inefficient. Using stream APIs like SAX or StAX to process XML is normally more efficient.
• SAX is a "push" API, where the SAX content handler calls your content handler whenever it receives a new XML event.
• StAX is a "pull" API, where the application runs through the XML events using an explicit loop to drive the processing.
• There are some really fast parsers and some pretty slow ones - you should choose an implementation that provides sufficient speed for your application.
• The interviewee considers Woodstox to be possibly the fastest open source XML parser.
• The interviewee considers JiBX fastest framework for streaming to objects - it works by building a compiled reader which is specific to your domain object.
• Fast InfoSet writes the XML as binary data, so it can provide a little bit more performance in some cases, at the expense of more CPU used. But standard compression of the XML could work too - it all depends on the characteristics on the application.
• In some applications where the namespace is very complex or large compared to the amount of data, it may make sense to minimize the namespace overhead. But this is a rare situation.
• If you're doing web browser interaction, interviewee recommends dropping XML and using JSON instead.

http://www.componenthouse.com/article-21
Ten UI Lessons from the Real World (Page last updated March 2008, Added 2008-03-30, Author Hugo Vidal Teixeira, Publisher componenthouse). Tips:

• If you add an icon to your application, make sure it is understandable. It should be clear what it represents to random users.
• Keep unrelated information clearly separated from each other.
• Missing punctuation can give completely misleading information. Make sure you punctuate to give the information you are intending to give.
• Avoid redundancy and strive for simplicity in your UI and messages. The simpler the UI, the more easily understood it is, and the more efficient it is.
• Look carefully at your UIs and search for conflicting ideas and difficult to understand messages and actions.
• Keep the information delivering content of the UI to the minimum required - extra information causes confusion and reduces the speed of comprehension.
• Typos are distracting and can lead to confusion.
• A message with a wrong meaning is worse than a typo - you can give completely the wrong message.
• Alignment is important because users don't read text on the UI, they scan it. So, well aligned text and controls help divide the screen into digestible pieces of information.

http://prefetch.net/blog/index.php/2008/02/02/profiling-java-methods-with-the-heap-profiling-agent/
Profiling Java methods with the heap profiling agent (Page last updated February 2008, Added 2008-03-30, Author Ryan Matteson, Publisher Blog O' Matty). Tips:

• The Java SDK comes with a heap profiler agent, which provides facilities to profile memory usage, CPU utilization and lock contention.
• To load the profiler agent to profile CPU utilization, you can add the "-agentlib:hprof=cpu=times" option to your java command line, e.g. "java -Xms256m -Xmx256m -verbose:gc -agentlib:hprof=cpu=times App". Hit cntrl+C to stop the process, this will cause the agent to write the data it has collected to the file java.hprof.txt
• The byte code injection approach of hrpof's cpu=times option introduces a fair amount of overhead to the Java runtime - you can use the lower overhead "cpu=samples" option instead to sample the runtime environment at periodic intervals to see which methods are executing. While this approach is not as accurate, it provides a good set of results with less runtime overhead.

http://www.ibm.com/developerworks/java/library/j-ibmtools1/index.html
Diagnostic and Monitoring Tools for Java - Dump Analyzer (Page last updated October 2007, Added 2008-03-30, Author Helen Beeken, Daniel Julin, Julie Stalley, Martin Trotter, Publisher IBM). Tips:

• [Article introduces the IBM Diagnostic and Monitoring Tools for Java - Dump Analyzer]
• It can be extremely difficult to diagnose an out of memory problem because the memory allocation that caused the failure is unlikely to itself be the ultimate culprit. It is normally necessary to examine the contents of the heap and to compare snapshots of the heap taken at various times so as to identify collections that have grown beyond expectation.
• A deadlock is a condition in which two or more processes are waiting for another process to release a resource. Deadlocks are relatively easy to diagnose by examining the states of the threads and the resources that they own.
• An IBM JVM system dump is generated by default when the VM crashes; however, the VM can be configured to create such a dump under other failing circumstances or at the user's request.

http://unenterprise.blogspot.com/2008/01/java-collections-and-concurrency.html
Java collections and concurrency (Page last updated January 2008, Added 2008-03-30, Author David MacIver, Publisher DesperatelyUnEnterprise). Tips:

• Concurrency is not an afterthought. If you're going to be doing concurrent programming you should be using datastructures designed for concurrent use. java.util.concurrent has a number of good ones.
• Avoid explicitly synchronizing if at all possible and have your structures be internally threadsafe.
• The author advocates never using the various synchronized wrapping classes available from the Collections class, such as synchronizedList, synchronizedMap, etc.
• Build internally synchronized structures with a ReentrantReadWriteLock rather than synchronization.
• The problem with using synchronized is that you have to use it on every single access to a structure (more or less) or your code is incorrect.
• Make you model as stateless as possible. Any classes containing mutable state must be internally synchronized, preferably using some explicit read/write lock. An alternative is to communicate using messages.

http://www.artima.com/cppsource/how_to_go_slow.html
How To Go Slow (Page last updated February 2008, Added 2008-03-30, Author Greg Colvin, Publisher Artima). Tips:

• If you have a choice of algorithms, go for the one that scales the slowest (e.g. linear rather than quadratic).
• It is easy to go super-linear without knowing, for example invoking an O(N) library routine N times. Another example: search algorithms in the C+ Standard are O(log(N)) with random-access iterators, but O(N) when used with input iterators.
• You might miss problems with fast development machines and small test cases, but which show up with more data and/or on slower machines - always test with the target amount of data and target architecture hardware.
• Spinning is looping while waiting for sme resource to come available. In these cases, you should sleep and yield the CPU for as much as possible rather than hog the CPU.
• For function calls that can block (has to wait on an event), make sure you timeout the call. If necessary run the call in a separate thread or process that can be killed when it appears to hang.
• Use asynchronous I/O to avoid ever waiting at all.
• Ensure that you always acquire a set of resources in the same order to minimize the chances of deadlocking.
• Lay out your data in memory so that the elements needed by each CPU are on separate cache lines. This may mean breaking up logical structures and spreading their elements across multiple arrays, in a pattern reminiscent of old-school FORTRAN. Try to work with how the CPU will cache elements, rather than against (iterating over the row in the tightest loop may help).

http://java.sys-con.com/read/487559.htm
Walking the Java Heap with NetBeans 6.0 Profiler (Page last updated January 2008, Added 2008-03-30, Author Tim Boudreau, Publisher JavaDevelopersJournal). Tips:

• Polling is low overhead, and useful when you know you might have a performance problem somewhere, but haven't localized it yet, and want a general picture of the hot spots.
• Full instrumentation is high overhead, but you get a detailed picture of what's happening in the JVM.
• Netbeans profiler injects profiling code into a running application, potentially only into a particular part of the application - you can choose to profile only one method, the rest of the application runs at full speed.
• NetBeans 6.0 introduces support for heap dumps. It can generate dumps, and read those generated by the JVM in the hprof format.
• A memory leak is an object that's no longer needed but is still referenced by another object that is needed. So the unneeded object remains in the heap, using memory that could otherwise be reclaimed.
• When you fix a memory leak, it's worthwhile to add a unit test to your project's test suite that proves the memory leak remains fixed.
• A way to regression test for a fixed memory leak is to create a weak reference to the object, exercise the code that used to cause the memory leak, then full GC (and run finalizers) several times and then check that that the weak reference now has a null referent.

Jack Shirazi Back to newsletter 088 contents