.NET 4.0 运行时是否比 .NET 2.0 运行时慢？
在我将项目升级到 .NET 4.0（使用 VS2010）后，我意识到它们的运行速度比在 .NET 2.0（VS2008）中慢。所以我决定在 VS2008 和 VS2008 中对一个简单的控制台应用程序进行基准测试。 VS2010 与各种目标框架：
using System;
using System.Diagnostics;
using System.Reflection;
namespace RuntimePerfTest
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Assembly.GetCallingAssembly().ImageRuntimeVersion);
Stopwatch sw = new Stopwatch();
while (true)
{
sw.Reset();
sw.Start();
for (int i = 0; i < 1000000000; i++)
{
}
TimeSpan elapsed = sw.Elapsed;
Console.WriteLine(elapsed);
}
}
}
}
这是结果：
- VS2008
- 目标框架 2.0：约 0.25 秒
- 目标框架 3.0：约 0.25 秒
- 目标框架 3.5：约 0.25 秒
- VS2010
- 目标框架 2.0：约 3.8 秒
- 目标框架 3.0：约 3.8 秒
- 目标框架 3.5：约 1.51 秒
- 目标框架 3.5 客户端配置文件：约 3.8 秒
- 目标框架 4.0：约 1.01 秒
- 目标框架 4.0 客户端配置文件：~1.01 秒
我的初步结论显然是，用 VS2008 编译的程序比用 VS2010 编译的程序运行得更快。
谁能解释一下 VS2008 和 VS2010 之间的性能变化？以及 VS2010 本身内部的不同目标框架之间？
After I upgraded my projects to .NET 4.0 (With VS2010) I realized than they run slower than they were in .NET 2.0 (VS2008). So i decided to benchmark a simple console application in both VS2008 & VS2010 with various Target Frameworks:
using System;
using System.Diagnostics;
using System.Reflection;
namespace RuntimePerfTest
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Assembly.GetCallingAssembly().ImageRuntimeVersion);
Stopwatch sw = new Stopwatch();
while (true)
{
sw.Reset();
sw.Start();
for (int i = 0; i < 1000000000; i++)
{
}
TimeSpan elapsed = sw.Elapsed;
Console.WriteLine(elapsed);
}
}
}
}
Here is the results:
- VS2008
- Target Framework 2.0: ~0.25 seconds
- Target Framework 3.0: ~0.25 seconds
- Target Framework 3.5: ~0.25 seconds
- VS2010
- Target Framework 2.0: ~3.8 seconds
- Target Framework 3.0: ~3.8 seconds
- Target Framework 3.5: ~1.51 seconds
- Target Framework 3.5 Client Profile: ~3.8 seconds
- Target Framework 4.0: ~1.01 seconds
- Target Framework 4.0 Client Profile: ~1.01 seconds
My initial conclusion is obviously that programs compiled with VS2008 working faster than programs compiled with VS2010.
Can anyone explain those performance changes between VS2008 and VS2010? and between different Target Frameworks inside VS2010 itself?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想我已经明白了。
如果您在 64 位计算机上运行，请确保构建设置为“任何 CPU”而不是“x86”。这样做解决了我机器上的问题。
VS2010 中新项目的默认设置从“任何 CPU”更改为“x86” - 我相信这是为了使“编辑”和“继续”默认在 64 位计算机上工作（因为它仅支持 x86）。
在 64 位机器上运行 x86 进程显然有些次优。编辑：根据达斯汀的评论，运行 x86 而不是 x64 在更有效地使用内存（更短的参考）方面可以具有性能优势。
我还通过电子邮件与达斯汀联系了此事，他列举了以下原因：
I think I've got it.
If you're running on a 64 bit machine, make sure the build is set to "Any CPU" rather than "x86". Doing that fixed the issue on my machine.
The default for new projects changed in VS2010 from "Any CPU" to "x86" - I believe this was to make Edit and Continue work by default on 64 bit machines (as it only supports x86).
Running an x86 process on a 64 bit machine is obviously somewhat suboptimal.EDIT: As per Dustin's comments, running x86 rather than x64 can have performance advantages in terms of more efficient use of memory (shorter references).
I also corresponded with Dustin about this by email, and he included these reasons:
我相信你的基准是有缺陷的。示例程序的 VS 2008 和 VS 2010 中的 IL 代码在发布模式下是相同的（VS 2008 面向 .NET 2.0，VS 2010 面向 .NET 4.0，使用默认设置）。因此，您不应该看到 VS 2008 和 VS 2010 之间的计时差异。两个编译器都会发出以下代码：
可能不同的一件事是平台目标。 VS 2010 使用 x86 作为默认平台目标，而 VS 2008 使用 AnyCPU。如果您使用的是 64 位系统，这将导致 VS 2008 与 VS 2010 构建使用不同的 JIT 编译器。由于 JIT 编译器是单独开发的，这可能会导致不同的结果。
I believe your benchmark is flawed. The IL code from VS 2008 and VS 2010 for your sample program is identical in release mode (VS 2008 targeting .NET 2.0 and VS 2010 targeting .NET 4.0 with default settings). Therefore you should not see a difference in timings between VS 2008 and VS 2010. Both compilers emit the following code:
One thing that might be different is the platform target. VS 2010 uses
x86as the default platform target whereas VS 2008 usesAnyCPU. If you are on a 64-bit system this will result in different JIT compilers being used for the VS 2008 vs. VS 2010 builds. This might lead to different results as the JIT compilers are developed separately.我同意该基准是有缺陷的。
在 x86 情况下，大部分额外时间可能由 WoW 层占用。然而，在实际涉及内存的较长基准测试中，x64 进程固有的低效率很可能会超过 WoW 层的开销。事实上，如果基准测试是访问内存（通过创建和访问堆上的对象），您就会看到 WoW 层指针优化的好处。
I agree that the benchmark is a flawed.
Most of the additional time is likely taken by the WoW layer in the x86 cases. However, the inherent inefficiencies of an x64 process would very likely outweigh the overhead of the WoW layer in a longer benchmark that actually touches memory. In fact, if the benchmark were to access memory (by creating and accessing objects on the heap), you'd see the WoW layers pointer optimization benefits.
我们有同样的问题。将 wpf 项目从 .NET 3.5 (VS2008) 转换为 .NET 4 (VS2010) 后，GUI 的响应速度大大降低（每次单击几乎延迟 1 秒）。
经过一番调查，我们发现，这是因为 Visual Studio 2010 占用了更多的资源，并且当我们从 VS2010 调试时，一切都变慢了。当我们将构建的项目作为 .exe 运行时，它再次运行得很快。
We have the same problem. After converting wpf project from .NET 3.5 (VS2008) to .NET 4 (VS2010), the GUI is much less responsive (almost 1 sec delay for every click).
After some investigation, we figured, it is because Visual Studio 2010 sucks much more resources and everything is slower when we degub from VS2010. When we run the builded project as .exe it runs fast again.