Hmmm a fellow lover of CPU performance counter :). Couple of points : > although its sampling: only every 1/1000th instruction or so gets profiled when these

Hmmm a fellow lover of CPU performance counter :). Couple of points : > although its sampling: only every 1/1000th instruction or so gets profiled when these profilers get turned on Not always, modern CPU ( intel's at least, not sure about arm and AMD), you can control the recorded event and the sampling event (and sampling rate) seperatly. So you can actually both record load/store misses and sample on cache misses to avoid loosing any events. You still get some sampling artifacts like the fact that the triggering of event is biais in favor or start of Basic block or that some events can be shadowed by others ... > if your instructions are (on average), waiting 10ns per load/store, you know that you're operating at the L2 cache level or so. Not always, sometime if you have a chain of depends loads the resolution time of the load has more to do with data dependencies. Intel's CPU has a collection of "precise" events, around caches events, so it's easy to just deduce precisely where a given loads resolves most of the time by doing the ration of L-cache misses/L cache hit dirrectly) > When you see that some branch is mostly unpredicted, you know to focus on that branch/if statement to figure out how to get the branch predictor to work. The hardest part here is to understand if the branch is unpredicted because it's unpredictable or because the branch predictor is not performing as expected : Branch predictors are limited resources, they can't predict all branch all the time.