Is there a performance difference between WPF and Winforms?

Question

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

Answer 1

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.

Answer 2

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.

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.

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 compelled to go with it; if your developers are already experienced with WinForms, it remains a perfectly viable option.

---

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.

Answer 3

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

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

• 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.

---

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.

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:

---

Performance: When you compare WPF's memory usage against winforms for really simple UIs (a Window or Form containing only a TextBox for 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).

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 DependencyProperty system, which stores default property values in a single memory space rather than in a per-instance basis.

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.

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 Video it 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 guru that 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 DataGridView and TreeView). ALL WPF ItemsControls are already or can be made virtual by default with some simple Application-wide Styles.

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.

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

---

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.

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.

With customizability in particular, I will say that even if you do not plan 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

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 Mentality is really what most developers coming from other frameworks struggle with.

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.

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.

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 are the Application, not the Views.

Answer 4

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