A question related to performance came up today on a mailing list that I’m on, and I stated that the right way to do things was to do performance work based on measurements (ie don’t engage in speculative optimization).

Another list member wrote back and said, “I understand what you’re saying, but isn’t that at odds with what many books say about designing for performance?”

I wrote an answer, and decided that it would be a good thing to share. This is what I think about writing performant code -what do you think?

*****

Yes, those two perspectives (design up front vs measure and tune) are somewhat at odds with each.

To do good performance optimization requires that you understand the performance bottlenecks of the system. There are two ways to understand that: intuition, or measurement.

A considerable amount of performance work is done on intuition. The problem with intuition is that it turns out to be a poor predictor – the performance bottleneck in most systems ends up being somewhere different than where you expect it to be. There may be exceptions to this – consultants who repeatedly implement a similar design for different customers, perhaps – but for most software, you just don’t have a very good idea where the bottleneck is going to be.

While performance work is often enjoyable, it tends to be fairly time consuming. If you optimize an area that didn’t need to be optimized (ie your image shows up in 0.05 seconds instead of 0.07 seconds), you are spending time that you could be using to implement/polish other features, work on the performance of areas that do matter, or finish early. And you’re generally creating code that is harder to read and maintain.

So, that leaves measurement. The important dictum here is “measure early, measure often”. “Measure early” may even mean writing some prototype code to validate some overall assumptions about the system – is it possible to pull data from the database quickly enough over the existing network to support what you need to do? How fast can DirectX render a frame?

Many software projects have time devoted to “performance tuning”. This is a “good thing” if you spend the time on an ongoing basis, measuring and improving as necessary. It’s a “bad thing” if you finish your implementation and then start looking at performance, as the kinds of changes that improving performance requires are generally the kinds that you don’t want to be making in the endgame. I’ve seen lots of examples where you get to a point where you a) understand the perf issue and b) understand how to fix it, but can’t because of where you are in the development cycle.

Using agile methods can help. If you have good unit tests, performance refactorings are less risky, and if you run on a short cycle, it’s harder to put things off. But you need to develop a “performance culture” in the team so that they care about performance all the time.

Hope that makes sense.

Rory wrote a post entitled “Whole Brain Coding” a couple of days ago, in which he asserts that coding requires both the left and right halves of the brain, the left brain working on the sequential and analytical parts of the task, and the right brain working on the intuitive and holistic parts (reverse these if you live in the southern hemisphere…)

When things are going well and you’re in the “flow“, my guess is that you’re seeing involvement of both sides of the brain, but I’m not sure that that’s all there is to it (I’m not asserting that Rory said that). I did a few searches to try to see what research had been done into the “flow”, but didn’t come up with much. There is:

In the Zone: A Bio-Behavioristic Analysis of Csikszentmihalyi’s Flow Experience

but I have a hard time parsing sentences like:

Primarily, the decision making process behind such behaviors as disparate as creative thinking, problem solving, or walking to the store are all dependent upon and influenced by somatic or neural activation variables that are mediated by abstract environmental contingencies.

I think that’s saying, “The way we make decisions is dependent on what’s going on around us”, which makes me happy that I’m not a psychologist who has to read and write papers like that.

There’s also

Understanding the Psychology of Programming

which is a light intro to the topic.

On the whole math vs. coding thing, though I have a math minor and enjoyed my math classes up through linear algebra and multivariable classes, I ended up in software for two reasons:

1. There’s more opportunity in it
2. Coding is way easier than math for me

Cyrus takes on Hungarian Notation

I’ve written a fair bit of code that both uses Hungarian, and code that doesn’t use Hungarian. I think Hungarian works okay for C code, but when you get into the object oriented world, you can’t really come up with prefixes that are both meaningful and short, so I currently prefer the .NET style of naming.