.Net 3.5 Windows 窗体应用程序:64 位 Vista 上的 x86 与 x64 加载时间 [英] .Net 3.5 Windows Forms Application: x86 vs x64 load times on 64 bit Vista

问题描述

我们正在开发 Winforms 应用程序并正在优化启动时间.

We are developing a Winforms application and in the process of optimizing the start-up time.

该应用程序在 64 位 Vista 机器上运行.在我们的测试中，我们发现了一个看似反直觉的结果.其他一切都相同，在一半的时间内针对 32 位和 64 位加载.谁能解释一下为什么?

The app runs on 64 bit Vista machines. In our testing we found what seems like a counter intuitive result. All else equal, targeting 32-bit vs 64-bit loads in half the time. Can anyone shed some light as to why?

谢谢.

我们通过 ClickOnce 部署应用程序，根据我们的研究，它在一个独特的沙箱中启动应用程序.因此它总是冷启动，所以在这里寻求提高性能是徒劳的.

We deploy the app via ClickOnce which, from our research starts apps in a unique sandbox. Therefore it always cold-starts so looking to improve performance here was fruitless.

我们的主要问题是项目中存在 32 位 dll.一旦我们将项目定位在 x86(即使它在 x64 上运行)，加载时间就会减少一半.[/编辑]

Our main problem was the existence of 32-bit dlls in the project. Once we targeted the project at x86 (even though it runs on x64) the load times were cut in half. [/Edit]

推荐答案

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

.NET 3.5 SP1 gets its improved startup perf by no longer verifying the strong name of assemblies that come from trusted locations. A bit controversial in my book but somewhat defensible.

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

I did check if the 64-bit version of the CLR also bypasses that time-consuming step. Signed a DLL, put it in the GAC, then patched a byte. No complaints when loading the assembly. So it is not the SP1 startup pref improvement that explains the difference.

启动时间的其他因素有:- 从磁盘加载 CLR(仅限冷启动)- 为依赖程序集低头- JIT 编译启动代码

Other factors in the startup time are: - Loading the CLR from disk (coldstart only) - Groveling for the dependent assemblies - JIT compiling the startup code

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

Coldstart could well be a factor, you probably don't have other processes running that have the 64-bit version of the CLR loaded. Easy to eliminate by running a dummy .NET app while you do the test.

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

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.

64 位 JITter 是一个更难破解的难题.任意调用是假设 MSFT 没有像 32 位 JITter 那样花费那么多时间来提高它的性能.虽然没有任何证据支持.也很难衡量，您必须使用 Assembly.Load 加载程序集，然后计时 Activator.CreateInstance()，其中类构造函数调用尽可能多的代码.

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.

这篇关于.Net 3.5 Windows 窗体应用程序:64 位 Vista 上的 x86 与 x64 加载时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！