int,short,byte在背靠背for循环中的性能（背景：为什么要用int而不是byte或shortinC#）为了满足我自己对使用“适当大小”的整数与“优化”整数的优缺点的好奇心，我编写了以下代码，它强化了我以前对.Net中的int性能的现实主义（并在链接中对此进行了解释在上面的)中）它针对int性能而不是short或byte进行了优化。日期时间t;长a、b、c；t=DateTime.Now;对于(intindex=0;index<127;index++){Console.WriteLine(index.ToString());}a=DateTime.Now.Ticks-t.Ticks;t=DateTime.Now;for(shortindex=0;index<127;index++){Console.WriteLine(index.ToString());}b=DateTime.Now.Ticks-t.Ticks;t=DateTime.Now;for(byteindex=0;index<127;index++){Console.WriteLine(index.ToString());}c=DateTime.Now.Ticks-t.Ticks;Console.WriteLine(a.ToString());Console.WriteLine(b.ToString());Console.WriteLine(c.ToString());这给出了大致一致的结果，范围为...~950,000~2,000,000~1,700,000这与我期望看到的一致。但是当我尝试为每种数据类型重复循环时...t=DateTime.Now;对于(intindex=0;index<127;index++){Console.WriteLine(index.ToString());}for(intindex=0;index<127;index++){Console.WriteLine(index.ToString());}for(intindex=0;index<127;index++){Console.WriteLine(index.ToString());}a=DateTime.Now.Ticks-t.Ticks;这些数字更像是...~450~3100000~300,000我觉得这很费解。任何人都可以提供解释吗？注意：为了比较，由于字节值类型的范围，我喜欢将循环限制为127。这也是一种好奇行为，而不是生产代码微优化。首先，它不是针对int性能优化的.NET，它是机器优化的，因为32位是本机字大小（除非你在x64上，在这种情况下它是long或64位）。其次，您要在每个循环中写入控制台——这比递增和测试循环计数器要昂贵得多，所以您在这里没有测量任何真实的东西。第三，一个字节范围最大为255，因此您可以循环254次（如果您尝试执行255次，它将溢出并且循环永远不会结束-但您不需要在128处停止）。第四，您没有进行足够的迭代来进行分析。迭代128次甚至254次的紧密循环没有意义。您应该做的是将byte/short/int循环放在另一个迭代更多的循环中，比如1000万次，然后检查结果。最后，在计算中使用DateTime.Now在解析时会产生一些计时“噪音”。建议（并且更容易）使用Stopwatch类。最重要的是，这需要进行许多更改才能完成有效的性能测试。这是我认为更准确的测试程序：classProgram{constintTestIterations=5000000;staticvoidMain(string[]args){RunTest("字节循环",TestByteLoop,TestIterations);RunTest("短循环",TestShortLoop,TestIterations);RunTest("IntLoop",TestIntLoop,TestIterations);控制台.ReadLine();}staticvoidRunTest(stringtestName,Actionaction,intiterations){秒表sw=newStopwatch();sw.开始();for(inti=0;i这会在一个更大的循环（500万次迭代）中运行每个循环，并在循环内执行一个非常简单的操作（递增一个变量）。我的结果是：byteloop:ElapsedTime=00:00:03.8949910ShortLoop:ElapsedTime=00:00:03.9098782IntLoop:ElapsedTime=00:00:03.2986990所以，没有明显的区别。此外，确保你在发布模式下配置，很多人忘记并在调试模式下测试，这将显着降低准确性。大部分时间可能会花在写入控制台上。尝试在循环中做一些不同的事情......另外：这是我的基准：使用系统;使用系统诊断；publicstaticclassTest{constintIterations=100000;staticvoidMain(string[]args){Measure(ByteLoop);测量（短循环）；测量（IntLoop）；测量（背对背）；测量（委托开销）；}staticvoidMeasure(Actionaction){GC.Collect();GC.WaitForPendingFinalizers();GC.Collect();秒表sw=Stopwatch.StartNew();for(inti=0;iresultsin:ByteLoop:6585msShortLoop:6342msIntLoop:6404msBackToBack:19757msDelegateOverhead:1ms(thisisonanetbook-adjustthenumberofiterationsuntilyougetareasonable:)这似乎表明它基本上与您使用的类型没有显着差异。出于好奇，我修改了Aaronaught的程序并在x86和x64模式下编译了它。奇怪，Int在x64中工作得更快：86字节循环：经过时间=00:00:00.8636454短循环：经过时间=00:00:00.8795518US短循环：经过时间=00:00:00.8630357Int循环：经过时间=00：00:00.5184154UInt循环：运行时间=00:00:00.4950156长循环：运行时间=00:00:01.2941183ULONG循环：运行时间=00:00:01.302340964字节循环：运行时间=00:00:01.0646588短循环：经过时间=00:00:01.0719330US短循环：经过时间=00:00:01.0711545Int循环：经过时间=00:00:00.2462848UInt循环：经过时间=00:00:00.4708777长循环：经过时间=00：00:00.5242272ULONGloop:elapsedtime=00:00:00.5144035我尝试了上面的两个程序，因为它们似乎在我的开发机器上产生了不同的、可能相互冲突的结果。Aaronaughts测试安全带输出ShortLoop:ElapsedTime=00:00:00.8299340ByteLoop:ElapsedTime=00:00:00.8398556IntLoop:ElapsedTime=00:00:00.3217386LongLoop:ElapsedTime=00:00:006.78163IntegersJon的输出更快ByteLoop：1126msShortLoop：1115msIntLoop：1096msBackToBack：3283msDelegateOverhead：0msNothingJon在结果中调用tostring有一个很大的固定常量，如果在循环中完成的工作较少，它可能会隐藏可能的好处。Aaronaught使用的是32位操作系统，它似乎不像我正在使用的x64钻机那样使用整数。在3.33GHz的Corei7975上收集的硬件/软件结果禁用了Turbo并设置了核心亲和力以减少其他任务的影响。性能设置全部设置为最大，病毒扫描程序/不必要的后台任务暂停了具有11GB备用RAM和最小IO活动的Windows7x64Ultimate。在VS2008内置的发布配置中运行，无需附加调试器或分析器。可重复性最初为每个测试重复执行序列10次。变化可以忽略不计，所以我只发布我的第一个结果。在最大CPU负载下，执行时间的比例保持一致。在考虑CPU生成和Ghz分析后，在多个x64xpxeon刀片上重复运行给出大致相同的结果，Redgate/Jetbrains/Slimtune/CLR分析器和我自己的分析器显示结果是正确的。使用VS中的调试设置调试构建会像Aaronaught那样提供一致的结果。分析.Net代码很棘手，因为编译后的字节码在运行时环境中运行，可以对字节码执行运行时优化。在第二个示例中，JIT编译器可能发现了重复代码并创建了一个更优化的版本。但是如果没有任何关于运行时系统如何工作的详细描述，就不可能知道代码会发生什么。根据实验尝试和猜测是愚蠢的，因为Microsoft有权随时重新设计JIT引擎，只要它们不破坏任何功能。控制台写入与数据的实际性能无关。它更多地与与控制台库调用的交互有关。建议您在数据大小独立的那些循环中做一些有趣的事情。建议：位移，乘法，数组运算，加法，还有很多。。。以上就是C#学习教程：int,short,byte在背靠背for循环中的性能分享，如果对大家有用需要了解一下更多关于C#的学习教程，希望大家多多关注---本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
