.Net 3.5 Windows窗体应用程序：64位Vista上的x86与x64加载时间

问题描述：

该应用在64位Vista机器上运行。在我们的测试中，我们发现了什么似乎是反直觉的结果。所有其他条件都相同，只有一半的时间针对32位和64位的负载。任何人都可以阐明为什么？

谢谢。

[编辑] 我们通过ClickOnce部署应用程序，从我们的研究在独特的沙箱中启动应用程序。因此，它总是冷冰冰的，所以看起来提高性能在这里是徒劳的。

我们的主要问题是项目中存在32位dll。一旦我们将目标锁定在x86上（即使它运行在x64上），加载时间也会减半。

答

.NET 3.5 SP1通过不再验证来自受信任位置的程序集的强名称来获得改进的启动性能。在我的书中有点有争议，但有点辩护。

我确实检查了64位版本的CLR是否也会绕过那个耗时的步骤。签署一个DLL，放入GAC，然后修补一个字节。加载程序集时没有抱怨。所以这不是SP1启动前的改进，它解释了这种差异。

在启动时的其他因素包括： - 从磁盘上加载CLR（冷启动只） - 卑躬屈膝的依赖程序 - JIT编译启动代码

冷启动很可能是一个因素，你可能没有其他正在运行的加载了64位CLR版本的进程。通过在测试过程中运行一个虚拟的.NET应用程序很容易消除。

由于相同的原因，反刍组件可能需要更长的时间。 .NET程序集的64位ngen-ed映像不太可能位于文件系统缓存中。同样，容易消除与虚拟应用程序依赖于相同的程序集。

64位JITter是一个棘手的问题。一个任意的调用是假定MSFT没有像32位JITter那样花费那么多时间来做这个表现。尽管没有任何证据支持。也很难衡量，你需要用Assembly.Load加载一个程序集，然后调用Activator.CreateInstance（），类构造函数尽可能多的调用代码。

答

64位版本通常会在堆上使用两倍的内存：每个指针占用两倍的空间，并且.NET充满了指针。由于初创公司深受内存初始化的影响，这可能是部分额外开销的原因。另请参阅Donald Knuth's flame about 64-bit pointers。

答

请注意，根据微软的说法，.Net 3.5 SP1在启动性能方面包含了相当多的工作（对于某些应用程序来说，性能提高了40％），所以您可能会看到这是否也有帮助。