Question

我知道的所有.net配置文件都没有考虑到CPU缓存的影响。

鉴于从CPU缓存读取字段比从主存储器中读取字段快100倍，这可能是一个重要因素。（我只需要在answer）

中解释一下

我看到有太多人花了很长时间来加速循环，而分析器说这些循环很慢，而在现实生活中，cpu缓存使它们变得很快。

E.g我希望能够看到数据访问是否遗漏了很多cpu缓存，以及只是获得我可以信任的基本分析结果。

在过去，我发现通过使我的数据更加紧凑，它将全部适合CPU缓存，或者更改另一个数据访问可能会产生很大影响。 E.g。

AccessArrarFromStartAndDoSomething()  
AccessArrayFromEndAndDoSomethingElse()

那就好了

AccessArrarFromStartAndDoSomething()  
AccessArrayStartEndAndDoSomethingElse()

如果数组不适合CPU Cache，但很难找到那种类型的inprovment。

花费更多的cpu周期来使数据更小，以便它更适合CPU Cache，可以扩展很多系统，但大多数分析器会指向另一个方向。

Answer 1

我可能误解了您的问题，但我认为答案只是将您的探查器切换为高精度，低细节模式。一个例子是使用ANTS Performance Profiler's新的采样模式：

Answer 2

我见过太多人花了一个长时间加速循环a 探测器说实际上很慢生活中的cpu缓存使它们变得快速。

有些分析师非常擅长胡说八道。

您的总体目标是什么？你想让计算在更短的时间内完成吗？

如果没有，请忽略此答案。

如果是这样，你需要知道是什么造成了你可以摆脱的挂钟时间。

这不是关于计时的准确性。这是关于位置的准确性。我建议你真正需要知道的是哪一行代码都是1）负责花费合理的时间，2）可以做得更好或根本不做。这就是你需要知道的，因为如果没有这样的代码行，那么你要优化什么？

找到这样的代码行的一种很好的方法是1）在调用堆栈的挂钟时间（不是cpu-time）上取样的任何分析器 ，2）告诉你，对于出现在调用堆栈中的每个代码行（非函数），它出现的堆栈的百分比。您的优化候选线是具有较大百分比的线。（一些非网络示例：Zoom和LTProf。）

坦率地说，我使用的探查器就是你已经拥有的探测器。我只是在程序缓慢的时候暂停程序并查看堆栈。我不需要很多样品。实际上，如果有一行代码我可以不用，如果它出现在两个样本上，我知道它值得修复，并且到达那一点所需的样本越少，它更大。 Here's a more thorough explanation.

几乎总有多个“瓶颈”。所以我找到一个大的，修复它，再做一遍。修复瓶颈对剩余瓶颈的影响是 - 它使它们更大。这种“放大效果*允许你继续前进，直到没有更多的速度挤出来。