question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Creating resource dictionary through code behind lead to performance delay

See original GitHub issue

Problem description:

My application contains more than 50+ MS and 150 + custom control, each control style have been defined in separate resource dictionary file and merged MS control resource dictionary in custom control resource dictionary file. And when I have merge control resource dictionary into application resources property through code behind. I am facing serve performance delay in creating resource dictionary at code behind.

`private void Button_Click(object sender, RoutedEventArgs e) { stopwatch.Start(); for (int i=0; i <= 100; i++) { Application.Current.Resources.MergedDictionaries.Add(new ResourceDictionary() { Source = new Uri(“/ResourceDictionary-Performance-issue;component/MSControl/CustomControl.xaml”, UriKind.RelativeOrAbsolute) }); }

        stopwatch.Stop();

        MessageBox.Show("Time delay in adding resource:" + stopwatch.Elapsed.TotalSeconds);

} ` Also, I have tired to reproduce in simple application. Please find the demo application attached below:

Sample: ResourceDictionary-Performance-issue.zip

Replication procedure:

  1. Run the demo.
  2. Click button to merge 100 resource dictionaries to current application.
  3. It took more than 4.5 sec.

Actual behavior: Performance delay occurs when creating resource dictionary.

Expected behavior: Performance delay should not occurs when creating resource dictionary.

Can anyone suggest a solution regarding this how to avoid performance delay when creating resource dictionary at code behind.

Issue Analytics

  • State:open
  • Created a year ago
  • Comments:5 (4 by maintainers)

github_iconTop GitHub Comments

3reactions
batzencommented, Jun 6, 2022

Having a lot of resource dictionaries is expensive and probably the reason why WPF merges all it’s resources into one generic.xaml during compile. So i suggest you do the same. Feel free to use the tool/msbuild task i built for that https://github.com/batzen/XAMLTools#xamlcombine

1reaction
batzencommented, Jun 22, 2022

@SubashiniMahendran with my solution you can keep your files separate for development and use the combined file for production.

Read more comments on GitHub >

github_iconTop Results From Across the Web

WPF Performance using ResourceDictionary
In my WPF application I have a lot of XAML, So I'm little confused in using ResourceDictionary in WPF, Does using it fasted...
Read more >
XAML Anti-Patterns: Resource Overuse
Most WPF applications with performance problems have issues other than dynamic resources that make them slow. When Resources Turn into Anti- ...
Read more >
ResourceDictionary and XAML resource references
You can define your resources using a ResourceDictionary element from the Windows Runtime XAML. Then, you can reference your resources by using ......
Read more >
Optimize your XAML markup - UWP applications
Parsing XAML markup to construct objects in memory is time-consuming for a complex UI. Here are some things you can do to improve...
Read more >
Can't open Resource Dictionary - Developer Community
VS gets into weird state where can't open Resource Dictionaries anymore, need to restart VS to get it to open the files again....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found