C#中首个循环后添加Console.WriteLine为何影响后续循环性能

原因1：JIT优化决策改变 #

你新增的Console.WriteLine("1: " + sum)代码，首先改变了sum变量的生命周期属性：

• 注释该行时，第一个循环计算得到的sum没有任何消费场景，后续会直接被sum=0覆盖，属于死值。JIT在做优化时，会尝试消除和sum相关的冗余计算，甚至会调整第一个循环的指令排布，反而增加了额外的跳转或者对齐开销，导致第一个循环耗时偏高。
• 取消注释后，sum的计算结果被明确消费，JIT会按正常逻辑生成第一个循环的代码，反而减少了冗余的优化开销，所以循环1、2的耗时出现小幅下降。

同时新增代码会增加Do方法的整体IL大小，RyuJIT的激进优化（比如自动向量化、循环展开、边界检查消除）都有代码大小阈值，当方法大小超过阈值后，部分循环的优化会被取消：你测试中循环3的性能下降就是因为新增代码后，JIT不再对循环3做自动向量化优化，导致耗时上升。

原因2：CPU指令缓存被冲刷 #

Console.WriteLine是一个非常重的系统调用，内部会执行数百行托管+非托管代码，还会涉及内核态的IO操作。

• 注释该行时，第一个循环执行完后，后续循环2~5的机器码已经被预加载到CPU的L1指令缓存中，执行时不需要再从内存读取指令，性能更高，这也是注释状态下循环3的耗时比取消注释时低的核心原因之一。
• 取消注释后，Console.WriteLine的执行会把L1指令缓存中原本缓存的后续循环的机器码全部冲刷掉，循环2~3执行时需要重新从内存加载指令，因此出现性能下降。而循环4、5的代码本身非常精简，且循环5的指令序列是CPU优化过的指针操作，受指令缓存的影响极小，所以耗时几乎没有变化。

补充验证方法 #

如果要排除JIT优化的干扰，可以在测试前先调用一次Do方法预热，让JIT提前完成所有优化，再跑正式测试；也可以在项目文件中加入<TieredCompilation>false</TieredCompilation>关闭分层编译，再对比测试结果，就能排除JIT动态编译的影响。

内容的提问来源于stack exchange，提问作者waterhead