Go fast, it runs too slow, you've got to make the number show. Diddle de bop, da la de doop, sitting around and feeling groovy.

Speed Is as Speed Does
Many moons ago I was working on a project that had to be sped up and we had the benefit of a very experienced consultant to help us out. Fresh from his business-class flight and clutching his pay-as-you-go expense account lunch, our management team eagerly led him over to where our assembled developers waited in awe (and with a certain amount of natural coder-sapiens resistance to the hired gun who'd come to town to sheriff us).

Like a surgeon approaching a sick patient we expected a briefcase to be opened revealing dozens of tools for analyzing memory leakage, profiling garbage collection across multiple threads, searching out deadlocks and everything else we assumed was slowing down the program. Instead all he produced was a simple red stopwatch.

All that matters to the user is how long a given scenario takes and whether it's perceived as slow or not. The first thing to do was to identify which tasks were too slow, figure out what response time would be acceptable, and then keep working back against that benchmark.

Apples and Apples
The idea is to focus on real user scenarios and their actual end-to-end response times. Instead of our zippy high-end boxes, dust off older, slower machines and dedicate them to doing the benchmarks. Us spoiled developers often run the latest wizzo kit and don't appreciate the realities of the boxes our code actually runs (or walks on) in the field.

Look Under the Hood
Having identified the slow scenarios, the next step is to identify where the time is going. Probably no single tool can yield all that information, and techniques can vary from simple tracelogs of the current clock time at various stages in the program through to powerful local and total time method breakdowns. Garbage collection, file I/O, page faults, all need to be observed and understood.

Fix What's Broke, Forget What's Not
Looking at the analysis from the running application can yield a bunch of fix candidates. But rather than jumping in and starting to redesign everything, it's good to prove first that there will be a real benefit before doing any work. Like writing a unit test before programming, it may be better to create dummy fixes that simulate the corrected code without being functionally complete. The exercise might involve changing a method to hard coding a result instead of an expensive piece of computation, or putting data in a stale cache and running performance tests to see if the fancy auto-rebuilding dancing cache is really worth doing. Before creating a solution, you have to know there's a real problem as opposed to a perceived one you just feel like polishing. Patch fixes can be created for dummy fixes, applied and run against a full build on the benchmark box to see what affect they have and, by extrapolation, the benefit fully functional fixes will bring to the bottom line.

Optimize Code Paths
Sometimes single method calls result in an explosion of code where a leaf method is being executed thousands of times. With the execution time of the lowest-level method being gauged in fractions of milliseconds, this becomes significant. The solution is to rewrite the code path to avoid such a deluge. The change itself might not be particularly difficult but without a good tool to get the problem on the radar, perhaps as a result of an n squared or even n to the n algorithm, it might never even be considered a possible problem.

Minimize IO
One way to produce big performance improvements is to reduce the amount of file reads and writes and socket access. Some data needs to be re-read frequently because it's volatile, but objects such as icons or definition files are good candidates to access once and cache in library registries. Socket I/O is another place to look as well. We found that the problem with one application was in the latency of the conversation, not in the amount of data being sent across the wire. It was overcome by batching data packets together into larger-grained messages.

Cache Model Data
Using a cache to speed something up can be either a silver bullet or fool's gold. The latter is like someone who claims they get great mileage from their car by not driving it. If the program is fast enough to begin with, caches aren't needed, so the first port of call should be to see if there are other unexplored avenues to make things quicker. If a cache is required then it comes with the health warning that you not only have to build it, you need to know when the data you're caching might become stale.

Leave Your Assumptions at the Door
One of the most startling things about tuning a program is that sometimes a lot of fancy code that was initially designed to help performance isn't that useful. Ironically the clever algorithms might actually cause harm. While they may add nothing significant to the bottom line, they can make the code harder to read and understand and affect its maintainability. This is part of the philosophy behind the XP mantra "Make it work, make it right, make it fast." Until you know what's slow, don't try to make it faster.