讨论: WINUI 3.0 和 XAML *编译*性能

讨论: WINUI 3.0 和 XAML 编译性能 关于 XAML 性能（xaml 渲染的运行时性能）的讨论又出现了。我并不想完全偏离这个话题……因此，我要开启一个单独的讨论，探讨 xaml 编译器的性能。以下是讨论的起点。@jtorjo 说： > uwp 编译时间非常慢！（大致上，比 WPF 慢 6 倍 - 我使用目标版本构建 1809 - 构建 17783） 我完全同意。调试/运行迭代（开发“内循环”）与 wpf 或 winforms 或者其他大多数 U/I 技术相比，速度非常慢。这种生产力障碍似乎主要与 uwp-xaml 的编译有关。在“秋季创作者更新”之后，编译 uwp-xaml 的性能出现了大幅下滑。VS 社区中有许多关于性能问题的报告，包括我自己的： https://developercommunity.visualstudio.com/content/problem/376045/compilation-of-uwp-xaml-project-is-slower-when-tar.html 不要过于严厉批评，但我认为 Microsoft 还没有开始深入研究 .net 方面 UWP 的开发者生产力。或者至少他们没有直接解决问题的编译方面。他们投资了其他提高生产力的方法，如 xaml 编辑和继续、xaml 工作室等。虽然这些有帮助，但它们似乎是工作的方法，而且似乎可以做得更多。在我的社区帖子中提及性能后，开发工具团队发表了一份声明，但我已经找不到它了（可能被审查了）。团队在我的 developercommunity 帖子中添加了以下声明。该声明试图解释秋季创作者更新后的回退："您发现的这个性能问题是为了解决构建一致性问题引入的，特别是在增量编译器情况下。考虑到这一点，我们正在寻找方法来使其更好，以便减少编译时间影响。"以下是关于 UWP 编译性能的社区帖子（还有很多）： - https://developercommunity.visualstudio.com/content/problem/376045/compilation-of-uwp-xaml-project-is-slower-when-tar.html - https://developercommunity.visualstudio.com/content/problem/692141/build-time-of-uwp-c-projects-takes-too-long.html 我的理解是，Visual Studio 正在执行"CompileXaml"任务的重复迭代（即执行比合理更多的编译步骤） 我认为我们可以做的最有建设性的事情是提供硬性测量（来自 VS 输出窗口），以证实我们的亲身体验，即 uwp-xaml 项目的编译速度较慢。可能还没有足够的反馈和 C#/桌面开发者的指标。（我怀疑我们一开始就不够多。我怀疑 UWP/WINUI 的开发者基础仍然是 C++）。捕获硬性测量至关重要。我建议…