Click here to Skip to main content
15,036,441 members
Articles / Desktop Programming / WPF
Technical Blog
Posted 24 Nov 2014

Tagged as


20 bookmarked

WPF User Controls: Do Not Use Merged Dictionaries for Shared Resources

Rate me:
Please Sign up or sign in to vote.
4.95/5 (9 votes)
25 Nov 2014Apache2 min read
New instance of a merged dictionary will be created for every user control. This can (and does) lead to increased loading time and memory footprint.

Resource dictionaries in WPF are not shared, unless they are part of App.xaml. That is, if you have a user control that loads (and uses) some resource dictionary, new instance of the dictionary will be loaded for each instance of the user control. This can (and does) lead to increased loading time and memory footprint.

I wrote a test application that demonstrates the problem. Source code Visio diagrams


Main window has four user control objects: two of type UserControl1 (red) and two of type UserControl2 (yellow). I defined a class named BigFatObject that allocates 200MB of memory. As instances of the class are created, they get sequential numbers: #1, #2, etc. Each user control refers to one instance of BigFatObject from App.xaml and to another instance from Dictionary1.xaml. You can see that instance #1 from App.xaml is shared by all controls, but each control has its own instance from Dictionary1.xaml (#2, #3, #4, and #5 respectively).

As a result, the application has 5 (five) 200MB objects, and its memory footprint is over 1GB in size. In our production code private dictionaries contained not one big object, but lots of small objects (brushes, colors, styles, etc.). This affected not only memory footprint, but also the startup time. Each time a user control was created, the dictionary had to be processed and all objects in it re-created.

Here’s how I use a resource dictionary in my user controls:

<UserControl ...>
                <ResourceDictionary Source="Dictionary1.xaml"/>

Here’s the relationship between XAML files in the application:


And here’s the object graph:


You can easily observe the duplication.

The solution to this problem is to put shared resource in App.xaml or include your dictionary from App.xaml. If you don’t have control over App.xaml, manually load your shared resources in code as described in this StackOverflow article. If you continue to refer to shared resources from user controls, you will suffer from increased memory footprint and slow load times.


This article, along with any associated source code and files, is licensed under The Apache License, Version 2.0


About the Author

Ivan Krivyakov
Technical Lead Thomson Reuters
United States United States
Ivan is a hands-on software architect/technical lead working for Thomson Reuters in the New York City area. At present I am mostly building complex multi-threaded WPF application for the financial sector, but I am also interested in cloud computing, web development, mobile development, etc.

Please visit my web site:

Comments and Discussions

QuestionStatic instances Pin
pavele12-Apr-16 20:52
Memberpavele12-Apr-16 20:52 
GeneralMy vote of 4 Pin
MahBulgaria29-Nov-14 0:27
MemberMahBulgaria29-Nov-14 0:27 
GeneralRe: My vote of 4 Pin
Ivan Krivyakov6-Dec-14 6:19
MemberIvan Krivyakov6-Dec-14 6:19 
GeneralRe: My vote of 4 Pin
MahBulgaria8-Dec-14 2:39
MemberMahBulgaria8-Dec-14 2:39 
SuggestionTake a look at this Pin
azweepay25-Nov-14 19:33
Memberazweepay25-Nov-14 19:33 
Although this seems to break the VS designer, it still works:[^]

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.