CODEWITHSUNDEEP
c#wpfvisual-studioxamlvisual-studio-2012
SuicideSheep
SuicideSheep

Reputation: 5550

WPF XAML Editor causing high memory consumption

whenever i use xaml editor designer mode, there will be an instance of XDesProc.exe at Windows Task Manager and it consume very high memory that eventually make the application hangs while i debug.

What I usually do is i will kill it at Task Manager and the program can continue running but designer view will be gone. This problem only exist at particular project but I've no idea where to trace the problem. Any wild guess?

Upvotes: 2

Views: 788

Answers (2)

YvesScherdin
YvesScherdin

Reputation: 13

Short Answer:

Turn off the XAML designer in the options.

Long Answer:

I'm experiencing a similar issue. The XAML designer window uses a lot of RAM, and that happens already in the moment when the WPF project is loaded. Of course, later when testing it gets only worse, since the test consumes further memory. This could explain the 'hanging up' behaviour of the application while debugging.

If I disable the designer itself - as described by Microsoft in its performance optimiziation tips (search there for "Other tools and extensions" and "Disable XAML Designer") - it consumes much less memory (4 GB less in my case). Testing the app even without the designer will still consume a lot of memory later on, but the application might not hang up any more while debugging. Turning off diagnostics might also help a bit.

The option in VS 2022 should be in: Tools > Options > XAML Designer > Enable XAML Designer. After that, you need to restart MS Visual Studio. Albeit you have no designer then, you still will be able to edit the raw XAML file, which might be enough for smaller changes.

Upvotes: 0

ΩmegaMan
ΩmegaMan

Reputation: 31696

These things to attempt or keep in mind.

  • Is the latest update for visual studio installed? Even if it is, one may want to run it again and try Repair.
  • Look at the controls on the screen in question. Can checks to determine if in design time such as DesignerProperties.GetIsInDesignMode(this) be used to circumvent code which shouldn't be run in design time? Check constructors for such places to put that check.
  • Remove the controls one by one until the designer behaves normally (or within a reasonable speed). That may give you a direction on the issue.
  • Does the same happen in Blend?
  • Run it in Visual Studio 2015/Blend 2015, do the same things happen? Note, if money is a factor usage of Visual Studio Community 2015 edition will work.

Upvotes: 0

Related Questions