> This is a defeatist attitude that is basically saying "it's impossible" I did not mean it like that. I am using profilers to find slow code successfully as w

> This is a defeatist attitude that is basically saying "it's impossible" I did not mean it like that. I am using profilers to find slow code successfully as well. The problem is that such profiler won't find you a spot where one object is slowly loaded from memory because CPU was not smart enough to prefetch it in advance, even if you profile with something as precise as Intel PT. > saying they magically don't work because your program is special is ridiculous I did not say that. Once again, I am talking about specific question of finding cache stalls in your program, not generic profiling. > If you access memory addresses next to each other sequentially It is of course beneficial to do it that way but it may be not trivial when you have complex relationships between different objects. Besides, the point of profiling is to efficiently find where you may need to do such optimizations, just saying "layout your objects optimally" does not help. > You don't need an exact instruction and it probably wouldn't help you anyway Exact instruction will help me to understand what specific object caused memory stall. Maybe this is indeed not that important. > Also you are contradicting yourself here I meant that you can easily find slow functions if there are any. If instead you have functiions a, b, c called sequentially and working same amount of time, you don't have obvious place to look at - if function b can be optimized by introducing cache awareness but other ones cannot, profile won't help you.