By Kevin Tatterson
One of my strongest professional motivators is my product’s performance. Having written and tuned algorithms for over 20 years, I’ve cemented a belief that should already be intuitive: as you push an algorithm’s performance, the code complexity goes up, and the performance yield gets smaller and smaller.
With this awareness, it should be obvious that the best approach to tackling your product’s performance is to look for 'low hanging fruit'. I don’t want this blog to digress into a full lecture on every technique for tuning your app – but instead want to discuss the importance of making sure you approach your product’s performance in an orderly, sensible manner.
The following chart shows three curves. The area under each represents the 'performance potential'. The x-axis represents complexity, effort, and support cost. Observations:
- The typical application (the area of the 'typical' curve) is only exploiting about half its performance potential (the area under the 'limit' curve).
- 'Low-hanging fruit' efforts are on the left side of the plot. As the curves indicate, most of the performance wins are found here.
- Complex projects for improving product performance would show up on the right side of the plot.
The suggestion here is simple: try to keep your performance projects in the green quads. Be exhaustive in searching out the low-hanging fruit. When moving beyond low-hanging fruit, be careful to move left-to-right – and don’t simply jump into complex projects. Staying out of the yellow and red-quads is more difficult than it sounds. Developers love a challenge and sometimes forget the golden rule to "keep it simple".
As it turns out, time is the third dimension not shown in the plot. As your application evolves, new low-hanging fruit will appear. This is simply because the code is under flux – and algorithms will 'detune' over time. As such, my suggestion is to schedule a performance study every year or so. It should only take 2-3 weeks to profile/search for new low-hanging fruit.
