Takeaways

Here’s what you learned during this profiling session:

• Optimization with the profiler is a craft, not engineering.

  You must look at the data, make your best guess at what’s slow, change the code, reprofile, and see whether your optimization worked. Rinse and repeat. The best way to learn this craft is by doing it. The more you profile, the better you understand the results you get, and the better optimization guesses you make.

• Write tests before profiling.

  You’ll change the code a lot during profiling. Tests are your only way to ensure the program still does what it’s supposed to do.

• The profiler will tell you what to optimize or where to concentrate your optimization effort.

  In our profiling session example, the profiler focused our attention on column parsing. First, we optimized date parsing. Second, we got rid of regular expressions. Once we did that, it turned out there wasn’t much else to optimize.

• Optimize details, but never forget about the big picture.

  We had to go one layer of abstraction up to make our best optimization. It’s worth rethinking what the code does. When we did that, we rewrote the whole column parsing code instead of trying to squeeze bits of performance out of existing code.

• The profiler obscures measurements. Make sure you check with the real world.

  Our profiles gave us the wrong impression that function call cost matters. Actually, it doesn’t matter. The profiler has its own internal upkeep cost. For that reason, it’s important to confirm optimization by measuring your program’s execution time without the profiler.