WPF在.NET Framework 4.0中的启动速度很慢

Rob*_*ser 36 .net wpf performance 64-bit .net-4.0

我注意到如果我为任何CPU/x64构建我的WPF应用程序,启动(大约20秒)或加载新控件需要花费的时间比在x86上启动(在发布和调试模式下) ,在VS的内部或外部.甚至最简单的WPF应用程序也会出现这种情况.在这个MSDN线程中讨论了这个问题,但没有提供答案.这只发生在.NET 4.0中 - 在3.5 SP1中,x64与x86一样快.有趣的是,微软似乎知道这个问题,因为VS2010中新的WPF项目的默认值是x86.

这是一个真正的错误还是我做错了?

编辑:可能与此相关:C#.NET 4.0中的慢速数据绑定设置时间.我正在大量使用数据绑定.

Jos*_*osh 74

实际上,WPF应用程序的默认项目类型是x86有两个主要原因.

  • Intellitrace调试仅适用于x86,如果默认项目模板不能与其中一个明星功能一起使用,那么看起来会非常糟糕.
  • 许多开发人员仍然没有意识到他们的AnyCPU exe将在64位计算机上作为x64运行,并且惊讶地发现他们依赖的32位DLL在64位变量中不存在,例如OLEDB驱动程序,某些本机DLL等. .

至于您遇到的启动时间问题,它几乎与NGEN一样.由于x64和x86进程有不同的NGEN缓存,因此可能需要重建或更新64位NGEN缓存.尝试从提升的命令提示符运行以下命令:

CD C:\Windows\Microsoft.NET\Framework64\v4.0.30319
NGEN update
Run Code Online (Sandbox Code Playgroud)

这是为已经标记为NGEN的程序集重新构建本机映像的命令.如果程序集不在GAC中,那么对你的应用程序也可能没有任何好处,所以我不打算尝试这样做.但框架组件,工具包组件等都应该是NGEN.

(顺便说一下,当我运行上面有关无法加载的程序集的命令时,我确实遇到了几个错误.主要是SQL和Visual Studio程序集.)

  • HOLY****,它_WORKED _ !!! 我从来没有想过这一点.你真的不辜负你的姓,老兄.谢谢*1000! (14认同)
  • Jeebus,这个建议创造奇迹!他们是如何设法未能及时更新缓存的,看看它的影响?MS失败了.顺便说一下,在安装某些更新后,您似乎需要重做此功能. (3认同)