c# - 如何在 for 循环中访问集合 'Length' 属性

Question

我知道在下面的代码中，数组“Length”属性不会在每次循环迭代时都被调用，因为 Jit 编译器足够聪明，可以将它识别为属性(而不是方法)并优化代码以仅在内部存储值时调用它在临时变量中:

Int32[] myArr = new Int32[100];
for(Int32 index = 0; index < myArr.Length; index++) {
// Do something with the current item
}

因此开发人员无需尝试通过将长度缓存到局部变量来优化它。 我的问题:.Net 中的所有集合类型都是这样吗？例如，假设我有一个 List 并在 for 循环中调用“Count”属性。我不应该优化这个吗？

Answer 1

I know that in the following code array 'Length' property is not called on every loop iteration because Jit compiler is clever enough to recognize it as property (not method)

虽然 Length 从类型系统的角度来看是一个属性，但从抖动的角度来看，它是一个特殊的指令，只是用于加载数组的长度。这就是使抖动能够执行此优化的原因。

我还注意到有一个更大的优化你没有提到。检查长度很便宜。这里更大的优化是抖动可以忽略对数组索引操作的检查，因为它知道循环变量将始终在数组的边界内。由于这些检查可能会引发异常，因此通过消除它们，抖动可以更轻松地分析方法的控制流，因此可以潜在地对方法的其余部分进行更好的优化。

is it true for all collection types in .Net?

抖动允许对其他集合类型进行优化，前提是它可以证明这样做是正确的。无论它是否确实如此，您都可以使用科学进行测试；观察抖动产生的代码，看看有没有这个优化。我的猜测是抖动没有这种优化。

For instance, suppose I have a List and call 'Count' property in for loop. Shouldn't I optimize this?

现在我们来到了问题的真正症结所在。你绝对不应该优化这个。优化非常昂贵；你的雇主会为你优化代码的每一分钟支付报酬，所以你应该优化产生最大用户可观察到的胜利的东西。获取列表的计数需要纳秒。世界上没有任何程序在市场上的成功取决于是否有人从不必要地检查列表计数的循环中删除了几纳秒。

花时间进行性能优化的方法是首先有一个以客户为中心的目标。这就是让您知道何时可以停止担心性能并将钱花在更重要的事情上的原因。其次，每天衡量该目标的进展情况。第三，当且仅当您没有达到目标时，使用探查器来确定代码实际性能不足的地方。然后优化那个东西，只优化那个东西。

纳米优化不是设计性能的方法。它们只会让代码更难阅读和维护。在分析性能时使用良好的工程学科，而不是技巧和技巧的集合。