I was handed a task to test a change that a co-worker made. This is usually no big deal to handle given my familiarity with the code and with my co-workers. Except that, in this case, the co-worker was no longer at the company (the ensuing information is in no way my co-worker’s fault so please don’t read it that way). Reading the details about the change it turns out that my co-worker found a possible way to increase the performance of a regularly used program that has been considered slow.

The change itself was sensible and I understood why one would think that there was a performance benefit to the change. But, upon testing the change, there was very little difference in performance. There were other benefits to the change. However, given how the story was initially described, the performance became THE THING that everybody was looking for.

After testing the change I decided, at a different co-worker’s urging, to run a profiler against the program that was slow. And, wouldn’t you know it, an easy change unrelated to the original changes revealed itself as a performance bottleneck. The program was spending a fair amount of time doing some unnecessary string manipulation. I was able to implement a quick change and, after re-running my tests, showed that this provided an improvement in performance. However, even thought this change was the top reported item from the profiler, making the change to remove the offending calls only resulted in a small improvement.

This just goes to show that you don’t really know what to change until you know what is taking the most time. Even after you know what is taking up the most time in a program you need to understand WHAT it is doing and WHY. Without a good understanding of these things optimizations are not likely to make much performance difference and stand a good chance of making the code less readable.

TL;DR — Write your code to be readable. Write it with thoroughly tested versions of the best data structures and algorithms for the job that you’re aware of at the time. Don’t reinvent the wheel. And only optimize after you’ve proven where the bottlenecks are.