Finding the performance problems

Resolving performance problems can be a straightforward process ... if you have the right tools at your disposal. Borrowing directly from the excellent text ``Java Performance Tuning'' by Jack Shirazi, the basic process is:

1. Measure the performance of the application, using tools, and/or by instrumenting the code.
2. Identify the location of any bottlenecks.
3. Think of a hypothesis for the cause of the bottleneck.
4. Consider any factors that might refute your hypothesis.
5. Create a test to isolate the factor identified by the hypothesis.
6. Test the hypothesis.
7. Alter the application to reduce the bottleneck.
8. Test that the alteration improves the performance.
9. Repeat from step 1.

Or, my simplified version of the process:

1. Instrument your code and find the major bottlenecks, using the best tools available.
2. Fix the bottlenecks that are causing the biggest problems, don't worry about the others. If you can't fix it, avoid it.
3. If performance is now acceptable, celebrate. If not, repeat from step 1.

The reason I say ``fix the bottlenecks that are causing the biggest problems and don't worry about the others'' is that when you first start, you may see three bottlenecks like this:

1. examineContents() - 70%
2. extractContents() - 20%
3. parseAttachment() - 10%

(Note that this is greatly simplified here.)

What might happen is that if you fix the first problem shown in this list - the examineContents() method - problems 2 and 3 may no longer matter. It may be that the first method was calling the second and third methods quite a bit, but once you fix the first method the second and third are not called nearly as much, and hence become less of a bottleneck than they were.. So, don't worry about 2 and 3 at this point. Just fix #1, because that's your biggest problem, and fixing #1 may totally change your next profile.

In the following sections I'll demonstrate how easy it was to cure major performance problems with the devdaily.com EmailAgent.

The performance problems with my application were very difficult to troubleshoot without tools, primarily because there was no user interface. Sometimes when you have a GUI you can at least get a feel for what module might be slow, but with a command line program like this one that runs and then returns without comment whenever it is finished, it can be very hard to know where the bottleneck is, especially if you're not comfortable with the problem domain. In this case I had never written a mail client before, and really had no experience or guess as to where the slowness problem might be coming from.

The only way to work this out was to run Optimizeit on my program, and see what insights it would reveal.