我们正在开发一个 Winforms 应用程序，并正在优化启动时间。
该应用程序在 64 位 Vista 机器上运行。在我们的测试中，我们发现了一个看似反直觉的结果。在其他条件相同的情况下，目标 32 位和 64 位加载的时间减半。任何人都可以解释为什么？
谢谢。
[编辑] 我们通过 ClickOnce 部署应用程序，根据我们的研究，它在一个独特的沙箱中启动应用程序。因此它总是冷启动，因此在这里寻求提高性能是徒劳的。
我们的主要问题是项目中存在 32 位 dll。一旦我们将项目定位在 x86（即使它在 x64 上运行），加载时间就会减少一半。[/编辑]
通过不再验证来自受信任位置的程序集的强名称，.NET 3.5 SP1 获得了改进的启动性能。在我的书中有点争议，但有点站得住脚。
我确实检查了 64 位版本的 CLR 是否也绕过了那个耗时的步骤。签署一个 DLL，将其放入 GAC，然后修补一个字节。加载组件时没有投诉。因此，解释差异的不是 SP1 启动首选项的改进。
启动时间中的其他因素是： - 从磁盘加载 CLR（仅限冷启动） - 依赖程序集的 Groveling - JIT 编译启动代码
冷启动很可能是一个因素，您可能没有运行其他加载了 64 位版本的 CLR 的进程。通过在进行测试时运行虚拟 .NET 应用程序可以轻松消除。
Groveling assemblies could take longer for the same reason. It is unlikely that the 64-bit ngen-ed images of the .NET assemblies are in the file system cache. Again, easy to eliminate with the dummy app having a dependency on the same assemblies.
The 64-bit JITter is a tougher nut to crack. An arbitrary call is to assume that MSFT didn't spend as much time making that one performant as the 32-bit JITter. Nothing backed-up by any evidence though. Difficult to measure too, you'd have load an assembly with Assembly.Load, then time Activator.CreateInstance() where the class constructor calls as much code as possible.
64 位版本通常会在堆上使用两倍的内存：每个指针占用两倍的空间，而 .NET 充满了指针。由于启动受内存初始化的影响很大，这可能是额外开销的一部分。另请参阅Donald Knuth 关于 64 位指针的火焰。
请注意，根据 Microsoft 的说法，.Net 3.5 SP1 在启动性能方面做了相当多的工作（某些应用程序提高了 40%），因此您可能会看到这是否也有帮助。