(Measuring before and after applying an optimization is) more important these days. With optimizing compilers and smart virtual machines, many of the standard optimizing techniques are not just ineffective but also counterintuitive. Craig Larman really brought this home when he told me about some comments he received after a talk at JavaOne about optimization in Java. One builder of an optimizing virtual machine said, in effect,
“The comments about thread pools were good, but you shouldn’t use object pools because they will slow down our VM.”Then another VM builder said,
“The comments about object pools were good, but you shouldn’t use thread pools because they slow down our VM.”Not only does this reinforce the need to measure with every optimization change, it also suggests that you should log every change made for optimization (a comment tag in the source code is a good option) and retest your optimizations after upgrading your compiler or VM. The optimization you did six months ago could be your bottleneck today.
I’ve written before about the decay of machine-specific optimization. Even if your code isn’t run by a VM, I think it’s reasonable to expect that (at least some of it) might be run on a smartphone in the near future.