当前位置:  开发笔记 > 开发工具 > 正文

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

如何解决《.Net3.5WindowsForms应用程序:64位Vista上的x86与x64加载时间》经验,为你挑选了1个好方法。

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

该应用程序在64位Vista机器上运行.在我们的测试中,我们发现了一个看似反直觉的结果.所有其他方面都相同,在一半的时间内针对32位与64位负载.任何人都可以解释为什么?

谢谢.

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

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



1> Hans Passant..:

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

我确实检查了64位版本的CLR是否也绕过了这个耗时的步骤.签名一个DLL,把它放在GAC中,然后修补一个字节.装载组件时没有抱怨.因此,不是SP1启动pref改进解释了差异.

启动时的其他因素包括: - 从磁盘加载CLR(仅限冷启动) - 依赖程序集的Groveling - JIT编译启动代码

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

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

64位JITter是一个难以破解的坚果.一个任意的调用是假设MSFT没有花费那么多时间来使那个性能与32位JITter一样多.没有任何证据支持任何证据.很难测量,你已经用Assembly.Load加载了一个程序集,然后是时间Activator.CreateInstance(),其中类构造函数调用尽可能多的代码.

推荐阅读
夏晶阳--艺术
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有