WPF 和 Winforms 之间有性能差异吗？

Is there a performance difference between WPF and Winforms?

提问by mlw4428

The title pretty much says it all. I did some Googling, but the only information I can find is at least a year old, some of the info is older than Windows 7. So I'm curious, is there a performance penalty for using WPF?

标题基本概括了所有内容。我做了一些谷歌搜索，但我能找到的唯一信息至少是一年前的，有些信息比 Windows 7 还要早。所以我很好奇，使用 WPF 会降低性能吗？

Does it work faster for somethings (such as data binding) than what you'd have to hack together on WinForms?

对于某些东西（例如数据绑定），它是否比您必须在 WinForms 上一起破解更快？

This will be a project created with .NET, in case that matters to anyone.

这将是一个用 .NET 创建的项目，以防对任何人都很重要。

EDIT

编辑

This project I'm looking at would have a basic style of UI, however there could be a lot of information displayed (it's querying files/directories and displaying them on the screen). I have not decided if it will auto-refresh the screen, but I imagine it may.

我正在查看的这个项目将具有基本的 UI 样式，但是可能会显示很多信息（它正在查询文件/目录并将它们显示在屏幕上）。我还没有决定它是否会自动刷新屏幕，但我想可能会。

There will likely be a fair amount of controls, however nothing that anyone should consider "graphic" intensive.

可能会有相当数量的控件，但是没有任何人应该考虑“图形”密集。

I'm looking at performance then from a business application perspective.

我正在从业务应用程序的角度来看性能。

I do NOT plan to use 3rd party controls.

我不打算使用第 3 方控件。

采纳答案by Mike Strobel

There is no meaningful "yes" or "no" answer to this. It depends on many factors, including but certainly not limited to:

对此没有有意义的“是”或“否”答案。这取决于许多因素，包括但肯定不限于：

1. What kind of UI you are building.

   Obviously, the complexity of the views you are designing will factor in to performance on both platforms. They have different layout and rendering pipelines.

2. How effectively you optimize for performance on each platform.

   It is, of course, easy to implement poorly performing UIs with both platforms. Implementing a complex UI such that it performs very well requires knowing how to leverage each platform's strengths and weaknesses effectively.

3. Whether you are using out-of-the-box controls or third-party controls, and the quality of those controls.

   Items 1 and 2 carry over to any third-party components as well.

1. 你正在构建什么样的用户界面。

   显然，您正在设计的视图的复杂性将影响两个平台上的性能。它们有不同的布局和渲染管道。

2. 您在每个平台上优化性能的效率如何。

   当然，很容易在两个平台上实现性能不佳的 UI。实现一个复杂的 UI 以使其性能非常好，需要知道如何有效地利用每个平台的优势和劣势。

3. 无论您使用的是现成控件还是第三方控件，以及这些控件的质量。

   第 1 项和第 2 项也适用于任何第三方组件。

If you are an experienced and competent WinForms developer, then you probably already know how to create performant views in WinForms. The learning curve for WPF is steep; any seasoned WPF developer can tell you that. They will also tell you that you can use it to build rich UIs that perform well. That is also true. The same is true for WinForms.

如果您是一位经验丰富且能干的 WinForms 开发人员，那么您可能已经知道如何在 WinForms 中创建高性能视图。WPF 的学习曲线很陡峭；任何经验丰富的 WPF 开发人员都可以告诉您这一点。他们还会告诉您，您可以使用它来构建性能良好的丰富 UI。这也是事实。WinForms 也是如此。

Both platforms are mature. Both are used widely. Neither is likely to see any future improvements apart from bug fixes.

两个平台都很成熟。两者都被广泛使用。除了错误修复之外，两者都不太可能看到任何未来的改进。

All that said, if you are not already heavily invested in either platform, I would go the WPF route. It's a rich (albeit heavyweight) framework that can be made to perform well. The amount of effort required to make it perform well depends largely on the types of views you are creating, but I have built many high volume, high frequency data views with WPF. I have also built a visually rich strategy game with WPF. But don't feel compelledto go with it; if your developers are already experienced with WinForms, it remains a perfectly viable option.

综上所述，如果您还没有对这两个平台进行大量投资，我会选择 WPF 路线。它是一个丰富的（尽管重量级）框架，可以使其表现良好。使其表现良好所需的工作量很大程度上取决于您创建的视图类型，但我已经使用 WPF 构建了许多高容量、高频数据视图。我还用 WPF 构建了一个视觉丰富的策略游戏。但是，不要觉得被迫去用它; 如果您的开发人员已经熟悉 WinForms，它仍然是一个非常可行的选择。

---

---

Update:I think it is unlikely that WinForms support will be removed from .NET in the next few years, but if this is a concern, then I would go for WPF. The types of views you describe can be created in WPF easily enough. For comparison, I have several views capable of displaying 50,000 to 500,000 rows with 60+ columns; thousands of row updates per second; custom, multi-level sorting and grouping applied; custom filtering; custom summaries; all kept up to date in pseudo real time ("human" real time). Getting that level of performance was not easy, but it can be done. The volume and frequency of data you are describing should be considerably easier to achieve with either platform, and using only the built-in control suite.

更新：我认为在未来几年内不太可能从 .NET 中删除 WinForms 支持，但如果这是一个问题，那么我会选择 WPF。您描述的视图类型可以很容易地在 WPF 中创建。为了比较，我有几个视图能够显示 50,000 到 500,000 行和 60 多列；每秒数千行更新；应用自定义、多级排序和分组；自定义过滤；自定义摘要；所有都以伪实时（“人类”实时）保持最新状态。获得这种性能水平并不容易，但可以做到。使用任一平台并仅使用内置控制套件，您所描述的数据量和频率应该更容易实现。

回答by Federico Berasategui

If you're doing complex UIs, WPF is the way to go. winforms doesn't support anything.

如果您正在制作复杂的 UI，WPF 是您的最佳选择。winforms 不支持任何东西。

If you're doing simple UIs, WPF is the way to go, because:

如果您正在制作简单的 UI，WPF 是您的最佳选择，因为：

• it allows a much cleaner pattern (MVVM) as opposed to the horrible too-much-code-for everything procedural winforms approach.
• It has much greater DataBinding capabilities.
• If you ever need to customize anything, you can.
• It has built-in UI Virtualization.
• It is resolution independent by default.

• 它允许更清晰的模式（MVVM），而不是可怕的代码过多，适用于所有程序化的winforms方法。
• 它具有更强大的数据绑定功能。
• 如果您需要自定义任何内容，您可以。
• 它具有内置的UI 虚拟化。
• 默认情况下，它与分辨率无关。

---

---

If you're concerned about the long term:

如果您担心长期：

WPF is the way to go. The current / future Windows UI framework is WinRT XAML. It will be MUCH easier to eventually port your WPF app to WinRT XAML than a winforms app. And, since MVVM is really technology-agnostic, you could eventually reuse your ViewModels in ANY other UI technology.

WPF是要走的路。当前/未来的 Windows UI 框架是 WinRT XAML。最终将您的 WPF 应用程序移植到 WinRT XAML 比使用 winforms 应用程序要容易得多。而且，由于 MVVM 确实与技术无关，因此您最终可以在任何其他 UI 技术中重用您的 ViewModel。

Edit:Since I've been receiving many downvotes and there's a lot of discussion around this answer, I'm going to specifically focus on the OP's question and try to provide a rather objective answer:

编辑：由于我收到了很多反对票并且围绕这个答案进行了很多讨论，因此我将特别关注 OP 的问题并尝试提供一个相当客观的答案：

---

---

Performance:When you compare WPF's memory usage against winforms for really simple UIs (a Windowor Formcontaining only a TextBoxfor example), WPF seems to consume much more memory than winforms. This is due to the fact that the WPF framework is much larger than winforms and therefore it has many more "things to load" in order to work. This is also true when you compare the cold startup times (again, in a 1-control situation).

性能：当您将 WPF 的内存使用与真正简单的 UI（例如aWindow或Form仅包含 a TextBox）的 winform 进行比较时，WPF 似乎比 winform 消耗更多的内存。这是因为 WPF 框架比 winforms 大得多，因此它有更多的“要加载的东西”才能工作。当您比较冷启动时间时也是如此（同样，在 1 控制情况下）。

In contrast, when you create heavier UIs composed of several controls / Buttons / DataGrids / ComboBoxes / TextBoxes / etc (things that are really common in Business Applications) the difference starts to diminish until it even favors WPF. This is because WPF's DependencyPropertysystem, which stores default property values in a single memory space rather than in a per-instance basis.

相比之下，当您创建由多个控件/按钮/数据网格/组合框/文本框/等（在业务应用程序中非常常见的东西）组成的更重的 UI 时，差异开始缩小，直到它甚至有利于 WPF。这是因为 WPF 的DependencyProperty系统将默认属性值存储在单个内存空间中，而不是在每个实例的基础上。

WPF was intended to be used for complex / Rich UIs from the beginning and is optimized to work on situations where there are thousands of controls, rather than the 1-control case.

WPF 从一开始就旨在用于复杂/丰富的 UI，并且经过优化以适用于有数千个控件的情况，而不是 1 个控件的情况。

Another really important aspect to consider when comparing performance between WPF and winforms from a data-centric perspective is, as mentioned above, UI Virtualization. Just by looking at this Videoit becomes obvious that WPF performs much better in a situation where you need to display 20k rows in a ListBox. I've been told by a winforms guruthat winforms seems to also support that, but you need to resort to called P/Invoke due to winforms not properly supporting that, and from what he said it is not obvious to me if other controls aside from the ListBox also support that in winforms (such as the DataGridViewand TreeView). ALL WPF ItemsControlsare already or can be made virtual by default with some simple Application-wide Styles.

从以数据为中心的角度比较 WPF 和 winforms 之间的性能时，要考虑的另一个非常重要的方面是，如上所述，UI 虚拟化。仅通过观看此视频，很明显 WPF 在需要在ListBox. 一位 winforms 专家告诉我，winforms 似乎也支持这一点，但是由于 winforms 没有正确支持它，您需要求助于 P/Invoke，而且从他所说的情况来看，如果不考虑其他控件，这对我来说并不明显从 ListBox 也支持在 winforms 中（例如DataGridView和TreeView）。ItemsControls默认情况下，所有 WPF都已经或可以通过一些简单的应用程序范围样式设置为虚拟的。

Hardware Acceleration: you might think "I don't need this", but if you look around, there are thousands of situations where winforms will start flickering horribly when updating the UI, not necessarily in a complex drawing situation, but also when resizing a Window that contains many controls. There are ways to workaround this, but then again, you'd have to start losing time in fixing an issue that you should never have to begin with, instead of concentrating on your Business Logic. You will NEVER have this problem with WPF, not only because it is hardware-accelerated, but also because it is Vector based, rather than Bitmap based.

硬件加速：你可能会想“我不需要这个”，但如果你环顾四周，在更新 UI 时，winforms 会开始可怕地闪烁的情况有数千种，不一定是在复杂的绘图情况下，而且在调整大小时也是如此包含许多控件的窗口。有一些方法可以解决这个问题，但话又说回来，您必须开始浪费时间来解决您永远不必开始的问题，而不是专注于您的业务逻辑。WPF 永远不会有这个问题，不仅因为它是硬件加速的，还因为它是基于矢量的，而不是基于位图的。

Conclusion: While winforms may perform better in the 1-control case, WPF is a clear winner at all levels for real-world Datacentric UIs.

结论：虽然 winforms 可能在 1-control 情况下表现更好，但 WPF 在现实世界的以数据为中心的 UI 的各个层面上都是明显的赢家。

---

---

Aside from all this, and as mentioned by @Blam, choosing a technology requires that you analyze not only the performance aspects but also the scalability, customizability, maintainability, ease of development, long-term perspective, among many other things.

除此之外，正如@Blam 所提到的，选择一项技术不仅需要分析性能方面，还需要分析可扩展性、可定制性、可维护性、易于开发、长期观点等。

In all these aspects, WPF is again a clear winner. a well-designed WPF MVVM application has a really clean, concise, beautiful code-base. winforms, no matter how expert you are with it, will always force you into dirty code behind solutions, simply because it doesn't support really complex scenarios and requires custom code for almost everything one can think of.

在所有这些方面，WPF 再次成为明显的赢家。一个设计良好的 WPF MVVM 应用程序有一个非常干净、简洁、漂亮的代码库。winforms，无论你是多么的专家，总会迫使你在解决方案背后使用脏代码，仅仅是因为它不支持真正复杂的场景，并且几乎所有你能想到的都需要自定义代码。

With customizability in particular, I will say that even if you do notplan to ever create a Completely Custom, Rich UI, choosing WPF is still a much wiser decision, because with winforms, you can eventually hit a wall if you ever want to Display your Data in a format that's not supported by default. Then you will have to start suffering and losing your time with horrible techiques such as "Owner Draw", whereas in WPF all you need is a simple DataTemplate

特别是可定制性，我会说，即使您确实not打算创建一个完全自定义的丰富 UI，选择 WPF 仍然是一个更明智的决定，因为使用 winforms，如果您想显示您的默认情况下不支持的格式的数据。然后，您将不得不开始遭受诸如“所有者绘制”之类的可怕技术的痛苦和浪费时间，而在 WPF 中，您只需要一个简单的DataTemplate

Granted, WPF is complex framework, but it's not really the complexity of it what makes the steep learning curve, but rather the required Change of Mentalityis really what most developers coming from other frameworks struggle with.

诚然，WPF 是一个复杂的框架，但真正使学习曲线陡峭的并不是它的复杂性，而是所需的心态改变确实是大多数来自其他框架的开发人员都在努力解决的问题。

And, as mentioned above, it is important that you code against abstractions, rather than against a specific set of classes, so that your code can eventually be ported to other frameworks if ever needed. WPF allows for that, winforms does not.

而且，如上所述，重要的是您针对抽象而不是针对一组特定的类进行编码，以便您的代码最终可以在需要时移植到其他框架。WPF 允许这样做，而 winforms 不允许。

If you code on winforms, you will be stuck forever in winforms' incapabilities and code behind hacks. It is true that if you use MVP on winforms this is somewhat alleviated, but still the Presenters have a much tighter coupling with the UI framework than ViewModels in MVVM, which are completely UI-agnostic.

如果您在 winforms 上编码，您将永远陷入 winforms 的无能和黑客背后的代码中。确实，如果您在 winforms 上使用 MVP，这会有所缓解，但与 MVVM 中的 ViewModels 相比，Presenter 与 UI 框架的耦合仍然更加紧密，后者完全与 UI 无关。

If you code in WPF with XAML and MVVM, you can eventually replace the WPF XAML views for something else, and keep your ViewModels untouched, which means that you actually NOT have to rewrite your entire application from scratch, because the ViewModels arethe Application, not the Views.

如果您使用 XAML 和 MVVM 在 WPF 中编码，您最终可以将 WPF XAML 视图替换为其他内容，并保持您的 ViewModels 不变，这意味着您实际上不必从头开始重写整个应用程序，因为 ViewModels是应用程序，不是意见。

回答by steve konarski

I tried drawing a large amount of lines on a panel in winforms and the same dt on a canvas in using WPF and found the winforms creted the drwing in less than second, wheres WPF took many seconds, even though I ws using Pathgeometry in WPF rather than shpes

我尝试在 Winforms 的面板上绘制大量线条，并在使用 WPF 的画布上绘制相同的 dt，发现 Winforms 在不到一秒的时间内完成了绘制，其中 WPF 花费了很多秒钟，即使我在 WPF 中使用 Pathgeometry 而不是比形状

回答by Terry Mac

I've coded a number of application in MVVM pattern for both Windows Forms and WPF and when you compare the same application implemented on both, windows forms wins for data bound applications. You notice the affect more if you have more than one child datagrid bound to a single parent datagrid or structure, never understood why. So for business applications I always code in WPF only if I have to. I also find sorting and filtering is also easier on windows forms.

我已经用 MVVM 模式为 Windows 窗体和 WPF 编写了许多应用程序，当您比较在两者上实现的相同应用程序时，Windows 窗体在数据绑定应用程序中胜出。如果您有多个子数据网格绑定到单个父数据网格或结构，您会注意到更多的影响，永远不明白为什么。因此，对于业务应用程序，我总是只在必要时才使用 WPF 进行编码。我还发现 Windows 窗体上的排序和过滤也更容易。