我们正在开发Winforms应用程序，并正在优化启动时间。
该应用程序运行在64位Vista机器上。 在我们的testing中，我们发现什么似乎是一个直观的结果。 其他所有的情况相同，只有一半的时间针对32位和64位的负载。 任何人都可以谈到为什么？
谢谢。
[编辑]我们通过ClickOnce部署应用程序，从我们的研究开始在一个独特的沙箱应用程序。 所以它总是冷冷的开始，所以看起来提高性能在这里是徒劳的。
validation是否安装Visual C ++ 2008 SP1可再发行组件包没有在Windowsregistry中search？
为什么即使在NetworkStream.EndRead返回0字节后，我仍然在接收数据？
stringinput从文本框if / else
如何在WPF中使用DrawThemeTextEx
我们的主要问题是项目中存在32位dll。 一旦我们在x86上定位项目（即使它在x64上运行），加载时间减半。 [/编辑]
将unix时间戳转换为正常date（UWP）
如何命名已部署的应用程序？
单声道.NET项目是否包含在最stream行的Linux发行版的最新版本中？
如何保存表单的状态？
在Linux上部署ASP.NET MVC：最佳实践，工具和惊喜
.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％），所以你可能会看到这样做是否有帮助。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
