WPF 在 .NET Framework 4.0 中的 x64 上启动缓慢答案

【问题标题】：WPF slow to start on x64 in .NET Framework 4.0WPF 在 .NET Framework 4.0 中的 x64 上启动缓慢
【发布时间】：2010-06-01 03:23:38
【问题描述】：

我注意到，如果我为 Any CPU/x64 构建 WPF 应用程序，启动（大约 20 秒左右）或加载新控件的时间要比在 x86 上启动（在发布& 调试模式，在 VS 内部或外部）。即使是最简单的 WPF 应用程序也会发生这种情况。 this MSDN thread 讨论了这个问题，但那里没有提供答案。这只发生在 .NET 4.0 中——在 3.5 SP1 中，x64 与 x86 一样快。有趣的是，微软似乎知道这个问题，因为 VS2010 中新 WPF 项目的默认设置是 x86。

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

编辑：可能与此相关：Slow Databinding setup time in C# .NET 4.0。我正在大量使用数据绑定。

【问题讨论】：

标签： .net wpf performance 64-bit .net-4.0

【解决方案1】：

实际上，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

这是为已标记为 NGEN 的程序集重新构建本机映像的命令。如果程序集不在 GAC 中，它也可能对 NGEN 您的应用程序没有任何好处，所以我不会费心尝试这样做。但是框架程序集、工具包程序集等都应该是 NGEN 的。

（顺便说一句，我在运行上述关于无法加载的程序集的命令时确实遇到了几个错误。主要是 SQL 和 Visual Studio 程序集。）

【讨论】：

天哪，它工作了！！！我永远不会想到这一点。你真的不辜负你的姓氏，伙计。谢谢* 1000！
Jeebus，这个建议很有效！他们到底是如何设法使缓存保持最新状态的，并看到了这种影响？ MS的大失败。顺便说一句，您似乎需要在安装某些更新后重做此操作。
确认一下，经过几个小时的调试和研究bug，我已经运行了NGEN update，并且应用程序开始像地狱一样运行！！！非常感谢兄弟。
@josh 这在 Windows 10 中仍然相关吗？并更新了.Net版本？
非常感谢。由于依赖关系，我有一个需要以 64 位运行的项目，但是一旦我将其转换为 x64，它就不会运行 BackgroundWorker 进程。 NGEN 解决方案解决了这个问题。