.net - .NET 4.0运行时是否比.NET 2.0运行时慢？

Question

将项目升级到.NET 4.0(使用VS2010)后，我意识到它们的运行速度比.NET 2.0(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

Target Framework 2.0:约0.25秒

目标框架3.0:约0.25秒

目标框架3.5:约0.25秒

VS2010

Target Framework 2.0:约3.8秒

Target Framework 3.0:约3.8秒

目标框架3.5:约1.51秒

Target Framework 3.5客户端配置文件:约3.8秒

目标框架4.0:约1.01秒

目标框架4.0客户端配置文件:〜1.01秒

我的初步结论显然是，VS2008编译的程序比VS2010编译的程序运行更快。

谁能解释VS2008和VS2010之间的性能变化？ VS2010本身内部的不同目标框架之间？

Answer 1

我想我明白了。

如果您在64位计算机上运行，​​请确保将构 build 置为“Any CPU”而不是“x86”。这样做解决了我机器上的问题。

在VS2010中，新项目的默认设置从“任何CPU”更改为“x86”-我相信这是为了使“编辑并继续”默认在64位计算机上工作(因为它仅支持x86)。

在64位计算机上运行x86进程显然有些欠佳。

编辑:根据Dustin的评论，就更有效地使用内存(较短的引用)而言，运行x86而不是x64可以具有性能优势。

我还通过电子邮件与Dustin进行了联系，他列举了以下原因:

FWIW, the default target platform wasn’t changed to support ENC. We had already shipped ENC broken on x64 for 2 releases. So by itself, ENC wasn’t really a compelling reason to switch. The primary reasons we switched (in no particular order) were:

• IntelliTrace is not supported on x64. So, one of the coolest new features won’t work on x64 Windows for Any CPU projects.

• x64 EXEs run slower on x64 Windows than x86 EXEs do. So, the idea of x86 debug, x64 release would mean that “optimized” builds in Release would actually perform worse.

• Customer complaints when deploying an application and finding that it doesn’t work, even though it worked on their machine. These were often around P/Invoke, but there any many other assumptions that can be made in an application that can break when run with different bitness.

The above reasons coupled with the fact that an Any CPU brings no benefits (i.e. you can’t actually take advantage of the expanded address space because the EXE may still run on x86) was the reason that the default was switched.

Rick Byers has an excellent post on this topic here.