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

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

该应用程序运行在64位Vista机器上。 在我们的testing中,我们发现什么似乎是一个直观的结果。 其他所有的情况相同,只有一半的时间针对32位和64位的负载。 任何人都可以谈到为什么?

谢谢。

[编辑]我们通过ClickOnce部署应用程序,从我们的研究开始在一个独特的沙箱应用程序。 所以它总是冷冷的开始,所以看起来提高性能在这里是徒劳的。

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

Solutions Collecting From Web of ".Net 3.5 Windows窗体应用程序:64位Vista上的x86与x64加载时间"

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

我确实检查了64位版本的CLR是否也绕过了那个耗时的步骤。 签名一个DLL,把它放在GAC中,然后修补一个字节。 加载程序集时没有抱怨。 所以这不是SP1的启动前期改进,解释了不同之处。

启动时间的其他因素是: – 从磁盘加载CLR(仅限于冷启动) – 相关程序集的变形 – JIT编译启动代码

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

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

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

64位版本通常会在堆上使用两倍的内存:每个指针占用两倍的空间,并且.NET充满了指针。 由于启动很大程度上受内存初始化的影响,这可能会占用部分额外开销。 另请参阅Donald Knuth关于64位指针的消息 。

请注意,根据微软的说法,.Net 3.5 SP1在启动性能方面包含了相当多的工作(一些应用程序的性能提高了40%),所以你可能会看到这样做是否有帮助。