收藏怎么样'；长度'；在for循环中访问的属性

本文关键字：访问 属性 循环 怎么样 长度 收藏 for | 更新日期: 2024-09-27 06:40:34

我知道，在下面的代码中，并不是每次循环迭代都会调用"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"属性。我不应该对此进行优化吗？

收藏怎么样'；长度'；在for循环中访问的属性

我知道在下面的代码中，数组"Length"属性并不是在每次循环迭代中都调用的，因为Jit编译器足够聪明，可以将其识别为属性（而不是方法）

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

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

对于.Net中的所有集合类型都是这样吗？

如果可以证明这样做是正确的，则允许对其他收集类型进行抖动优化。无论它是否真的这样做，你都可以用科学来测试；观察抖动产生的代码，看看它是否有这种优化。我的猜测是抖动没有这种优化。

例如，假设我有一个List，并在For循环中调用"Count"属性。我不应该对此进行优化吗？

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

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

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

相关文章：