JavaOne 2010: Performance Tuning from the Pros

John Duimovich ("special guest") presented Trent Gray-Donald's  (IBM Java) "Performance Tuning from the Pros" presentation to a well-beyond-standing-room-only audience at JavaOne 2010. According to Duimovic, Trent keeps tweaking this presentation between times that he gives it.

Garbage collection tuning is part of performance tuning, but it's not all there is to performance tuning. The slide "Avoiding panic" had an important point: don't worry about slow-performing features that no one uses. The idea here is to "frame the problem" first. This helps to identify appropriate approach to meet those needs and desires. As part of framing the problem, it's also important to identify what we are allowed to change. "It's just too slow" doesn't give any information as to what is needed, so there's no good way to get there.

Another good point is to "don't just 'try things.'" Duimovich said that using what worked from last time again simply because it worked before is like taking a prescription from a previous illness when sick again.

A "key insight" cited in this presentation is one I've written about before: "Gathering performance data affects the results." Several attendees (including me) could relate when Duimovich asked how many of us have added logging to help diagnose performance problems only to find out that excessive logging is the problem.

Duimovich stated that we need to understand the constraints that impact performance and he outlined the common ones. He then laid out how to apply "Scientific method" to tune performance. This includes changing one thing at a time, keeping a log of changes, using consistent measurements, and recording in detail the results of what was attempt. In short, you need "good discipline" when tuning performance.

Duimovich moved onto some specific approaches for performance tuning. He stated that the time for tuning with tooling is throughout the development cycle waiting until the end when panic mode will inevitably set in.

At this point, Duimovich went through some example performance tuning steps against some code obviously written to demonstrate performance problems that could be resolved, but also intended to make it easy to guess (wrongly) about what was causing the performance issue. He showed how using the tools to try changes one-at-a-time could help identify the real problems, which were not always what was first expected from looking at the code.

Duimovich used several tools including Health Center and Eclipse Memory Analyzer. Although you shouldn't try to just guess what's wrong, Duimovich did say that very often its heap abuse and Eclipse Memory Analyzer can point this out. Eclipse Memory Analyzer can be used with any JVM. He said he often finds collections on the heap with one or two elements.

Duimovich outlined some rules for "modern JVMs."  The first was to "write readable code." The second was to "follow JVM strengths" (use JDK libraries and don't inline) and the third was to "leverage multi-core if appropriate." Generally use class libraries, but in some cases measurement and analysis may show that a custom solution is necessary.

Things not to do in performance tuning include trying to use "hail mary" magic JVM command-line options and trying to guess at what's causing the performance problems.

This was the third session that I attended at which a substitute speaker presented the prepared presentation. As with the first two, this substitute speaker did an admirable job.