foreach和收集的使用是否缓慢？

Question

我正在重构我的应用程序以加快速度.我正在寻找这样做的提示,并发现了这个声明:

"ForEach可以简化For循环中的代码,但它是一个繁重的对象,并且比使用For编写的循环慢."

真的吗？如果它是在写的时候是真的,今天它仍然是真的,还是已经重构以改善性能？

我对来自同一来源的这个提示有同样的疑问:

"尽可能使用数组而不是集合.数组通常更有效,特别是对于值类型.另外,尽可能将集合初始化为所需的大小."

UPDATE

我正在寻找性能提示,因为我的数据库操作需要几秒钟.

我发现"使用"声明是一个耗时的时间.

我完全通过反转for循环和"使用"来解决我的性能问题(当然,重构是必要的).

比糖蜜更慢的代码是:

for (int i = 1; i <= googlePlex; i++) {
    . . .
    using (OracleCommand ocmd = new OracleCommand(insert, oc)) {
    . . .
    InsertRecord();
    . . .

速度超快的子弹代码是:

using (OracleCommand ocmd = new OracleCommand(insert, oc)) {
    for (int i = 1; i <= googlePlex; i++) {
        . . .
        InsertRecord();
        . . .

Answer 1

简短回答:

难以阅读的代码最终会导致软件表现不佳并且表现不佳.

答案很长:

早期的.NET中存在一种微优化建议的文化.部分原因是因为一些微软的内部工具(如FxCop)在一般公众中受到欢迎.部分原因是因为C#拥有并希望成为汇编,C和C++的继承者,关于在性能关键应用程序的几个最热门代码路径中不受阻碍地访问原始硬件性能.当然,这确实需要比典型应用更多的知识和纪律.框架代码和应用程​​序代码中与性能相关的决策的后果也大不相同.

当然,这对C#编码文化的净影响是积极的; 但它是荒谬的停止使用foreach或is或""只是为了节省几个CIL说明你最近的抖动很可能优化完全消失,如果它想.

您的应用中可能存在很多循环,最多其中一个可能是当前的性能瓶颈.以可读性为代价"优化"非性能的性能是非常糟糕的.

Answer 2

在许多情况下,foreach它比同等速度慢for.这也是事实

for (int i = 0; i < myCollection.Length; i++) // Compiler must re-evaluate getter because value may have changed

比...慢

int max = myCollection.Length;
for (int i = 0; i < max; i++) 

但这可能根本不重要.有关非常详细的讨论,请参阅C#中的'和'foreach'的控制结构的性能差异

您是否进行过任何分析以确定应用程序的热点？如果循环管理开销是你应该集中注意力的地方,我会感到惊讶.