WebKit Never Gets Slower

I’m going to break radio silence to discuss this statement posted by the WebKit team on the subject of software performance. Summary: WebKit is fast because we’ve got performance tests and we never allow a regression:

Common excuses people give when they regress performance are, “But the new way is cleaner!” or “The new way is more correct.” We don’t care. No performance regressions are allowed, regardless of the reason. There is no justification for regressing performance. None.

I love WebKit (it’s blazing fast), and the team’s statement is very reassuring in that take-a-stand way. Unfortunately, I have to call bullshit.

Firstly, it’s important to note that a policy like this is only as good as your performance test suite. It’s very easy to accept a change which appears to have 100% positive benefit but is, in fact, a trade-off that you cannot measure because your test suite doesn’t tell the other side of the story. The WebKit team’s article admits as much, asking people to run their own performance tests and notify the team if badness occurs.

Even with an iron-clad test suite, we know software has bugs and that bugs must be fixed. One funny thing about high performance software is that, often, things can go really really fast when they are incorrect. I can optimize the hell out of any software provided it doesn’t have to get the right answer. To say that another way, bug fixes often regress performance. You can bet that the WebKit team fixes bugs. The product would not be useful otherwise.

Lastly, on what scale is the “no performance regressions” rule enforced? At most it can be per-check-in. It doesn’t take a genius to extrapolate from there. I’m sure WebKit has had plenty of check-ins which do more than one thing. Consider this imaginary check-in comment:

This change set refactors the Widget rendering code to make it more logical and less of a bug farm. It also memoizes the GetBestWidget function, improving performance on WidgetBench by 30%.

A cynical person (ahem) might say that this type of check-in actually does two, separable things, and that perhaps if we simply tolerated the original crappy bug-farm rendering code and added the optimization we’d have seen 35% gains.

Bottom line: things are never quite as simple as they seem.


%d bloggers like this: