One of our main roles in DevDiv Performance Engineering is to help other teams with performance investigations – that is, to help them understand why their code isn’t running fast enough. Recently we ran a little side project that was unusual in two respects: first, we were analyzing performance just for our own curiosity, and second, the investigation was triggered because Visual Studio benchmarks seemed to be running faster than expected on our new multi-core hardware. You might think that in this case we could just leave well enough alone – hey, if the benchmarks are meeting their performance goals then there’s no need to worry, right? – but good performance engineering doesn’t work that way. It’s a constant process of learning, and if you find something out of the ordinary that you didn’t expect, whether positive or negative, then it’s time to roll up your sleeves and figure out why.

The whole process turned into a nice detective story, with twists and turns along the way. You can read the whole thing over at “Lessons from the test lab: investigating a pleasant surprise”, but here’s the one-sentence summary: these aren’t your father’s processor cores anymore…