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

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.