The article is about Windows Form controls and WPF controls memory management, the difference between them and internals of how they are loaded.
Introduction
This is the analysis of the Windows Form controls and WPF controls and how they consume the memory of the system. It dives deep into the objects being created and memory footprint consumed by both application types.
Background
Windows Forms have been around since ages to develop applications on Windows platform. In 2007, WPF was introduced as a replacement to Windows Form application with new enhancements. This is the comparison of Windows Form application with a WPF application on the basis of memory utilization.
Using the Code
To compare both the Application Types, we would require the applications to be created with similar controls.
For this example, I have taken TextBox
control. The reason for choosing TextBox
controls is because in Windows Form Application, TextBox
Class is inheriting from System.Windows.Forms.Control
in (System.Windows.Forms.dll).
WPF Application TextBox
Class is directly inheriting from System.Windows.Controls.Primitives.Control
(PresentationFramework.dll).
Due to this, the TextBox
control in WPF does not inherit from ContentControl
thus avoiding an extra overhead of object creation.
Arguably, we could have used Windows form Label
with TextBlock
, but let's use TextBox
since almost all real world applications will use it somewhere or the other.
To begin with, we will create 1000 TextBox
objects on Windows form and WPF application and render them on screen. We will measure the memory utilization and check into how many objects are created and memory utilized to do the same.
Let's create a a simple Windows Form application and add the below code into it:
using System.Drawing;
using System.Windows.Forms;
namespace WindowsFormsPerformance
{
public partial class WindowsForm : Form
{
private System.Windows.Forms.TextBox textbox1;
int Iteration = 1000;
public WindowsForm()
{
InitializeComponent();
CreateMultipleTextControls();
}
public void CreateMultipleTextControls()
{
for (int i = 0; i < Iteration; i++)
{
this.textbox1 = new System.Windows.Forms.TextBox();
this.textbox1.Location = new System.Drawing.Point(10, 10);
this.textbox1.Name = "textbox" + i;
this.textbox1.Size = new System.Drawing.Size(150, 150);
this.textbox1.BackColor = Color.Blue;
this.textbox1.TabIndex = 0;
this.textbox1.Text = "textbox";
this.Controls.Add(textbox1);
}
}
}
}
Let's create a a simple WPF application and add the below code into it:
using System.Windows;
using System.Windows.Controls;
using System.Windows.Media;
namespace WPFWinPerformance
{
public partial class MainWindow : Window
{
int Iteration = 1000;
private TextBox textbox1;
public MainWindow()
{
InitializeComponent();
CreateMultipleTextControls();
}
public void CreateMultipleTextControls()
{
for (int i = 0; i < Iteration; i++)
{
this.textbox1 = new TextBox();
this.textbox1.Name = "textbox" + i;
this.textbox1.TabIndex = 0;
this.textbox1.Text = "Text";
this.textbox1.Width = 150;
this.textbox1.Height = 150;
this.textbox1.Background = new SolidColorBrush(Colors.DarkBlue);
this.textbox1.Margin = new Thickness(10, 10, 10, 10);
this.Grid1.Children.Add(textbox1);
}
}
}
}
The results are below when you run the application using Diagnostics Tool used in Visual Studio 2015.
For memory usage, there are two snapshots taken for checking the memory usage.
First snapshot after:
InitializeComponent();
Second snapshot after:
CreateMultipleTextControls();
1) Windows Application
Windows Summary: Here, in the first snapshot, 1247 objects were created and the application takes 94.35 KB size.
In the second snapshot, when 1000 Text Boxes were created, the rendered application had created 14327 objects and application size was 654.77 KB.
2) WPF Application
WPF Summary: Here, in the first snapshot, 12702 objects were created and application takes 595.80 KB size.
In the second snapshot when 1000 Text Boxes were created, the rendered application had created 4,04,324 objects and application size was 17,689.31 KB.
So definitely, WPF application takes up a lot of memory as compared to Windows Application. But it is understood that WPF gives much more flexibility than Windows in terms of look and feel of the controls, also WPF renders control according to visual tree which is also an overhead. Leaving all those extra bits aside, let's check out what other properties are utilizing memory in the application. Digging in the objects created, you can checkout the memory every object is consuming.
The below images show the Windows Forms application objects loaded in snapshot 1 and snapshot 2. It shows that Windows Forms on snapshot 1 hardly creates any heavy objects, the heaviest being icon and after rendering 1000 textboxes, the Textbox
and PropertyStore
take maximum memory which is expected since Property Store instance created for every control in Windows Form.
Snapshot 1
Snapshot 2
The below images show the WPF application objects loaded in snapshot 1 and snapshot 2. It shows the WPF application has few objects created like single instances of all Dependency Properties in the application and other basic objects which are required for the application. But snapshot 2 is a bit heavier since Textbox
class internally needs ScrollViewer
, Rectangle
, Border
, Vertical
/Horizontal
Scrollbar to be created, this shoots up the application size. It also has Dependency Properties being created but due to single instance of Dependency properties for same type, they have a smaller footprint unlike the one in Windows form where PropertyStore
got shot up when number of controls increased.
Snapshot 1
Snapshot 2
Conclusion
The summary of the details:
The above summary shows that WPF controls have much higher memory footprint than its counterpart Windows controls since WPF controls are designed in a different way and need more smaller units initialized to create a control. But one thing to observe is that WPF total load time is better than Win forms application. I am going to cover this in the next post as to why this has occurred.
Windows Form CPU Load
WPF CPU Load
Coding is Simple
History
- 10th October, 2015: Initial version