Monday, August 30, 2010

turbo = true

I have a client who is starting to look at the performance of their product. They've spent a good amount of time building the product, adding features, creating documentation, etc., but they haven't done anything explicitly to make it faster. And now it's time to make it faster.

A group of us working on the "performance improvement" project got together to talk about how we'd start going this, and the first question that came up was this:
"Well, which configuration are we going to do?"

This is a legitimate question. This software can be deployed in two different modes and several different sizes. Which one should we try to make faster first?

Here's a little secret from every single performance optimization effort I've worked on: It doesn't matter. If you haven't done any performance optimization at all, your first attempts will almost certainly help everything. It's like a global setting "turbo = true" in your code, that first round of performance enhancements.

Of course no one intentionally writes slow code, and we don't intentionally design it to be slow. But inefficiencies creep in. Maybe they're the fast way to implement something, maybe they're the easy way to implement it, Maybe it's a more junior developer who doesn't yet know that you don't do a linear search here because this data structure can get large. Whatever the cause, there's probably a bit of sloppiness, and fixing that will help performance across the board.

Pick a configuration to work on, absolutely. That will help the performance team produce comparable results and provide some focus. But don't stress too much over the choice. At least at the beginning, you're likely to improve more than the thing you're focusing on. Later on this will change, but for as long as it lasts, accept the turbo button you're enabling in your product.

No comments:

Post a Comment