❔ Release mode garbage collection is much longer than debug mode
I built a WPF app, and to test the lag, i'm just selecting a ListBoxItem and moving my mouse up and down (which generates lots of garbage due to WPF).
When i build my app in debug mode and run it in VS, the garbage collection is almost instant and there's practically no spikes or stoppages when constantly changing the selected item. But when i build it in release mode, every half a second there's a spike for about 600ms or so. What could be causing this? (I added a small progress bar to show the memory usage, and the usage drops after the large spikes in Release mode, but in debug mode it's like it just randomly drops)
16 Replies
600ms is insanely long for a GC, I'm skeptical that is actually a GC pause. You should take a performance profile.
The lag doesn't exist in the performance profiler, probably because it's running in debug mode 😦
In says the garbage collection is about 19ms, not sure about release mode though
Take an ETW trace of the release mode behavior.
Is that an external app or nuget library or something?
ETW is a technology in Windows for recording things like performance profiles. There are a variety of ways to take such traces (traditionally I have used the PerfView tool) but these days I find this tool the simplest to use to get an actual trace:
https://github.com/google/UIforETW
GitHub
GitHub - google/UIforETW: User interface for recording and managing...
User interface for recording and managing ETW traces - GitHub - google/UIforETW: User interface for recording and managing ETW traces
Just unzip it and run.
Then once you have a trace you can analyze it in something like Windows Performance Analyzer (warning: not very user friendly for beginners) or PerfView.
Analyzing such traces is kind of an advanced skill but if you're able to do it you should be able to see where all of that time is being spent during those long pauses.
I'm 99% certain it's the garbage collector
there's nothing else that could be causing such huge spikes in my code
A perf trace should show much time was spent in GC
Does c# does ahead of time compilation instead of JIT?
suppose it could be the compiler maybe but i dunno why it would be halting the UI thread...
AOT is a feature you can opt-in to but out-of-the-box it uses JIT
I found an email from Maoni (the dev who owns the GC) that suggests this for taking a perf trace that should show the GC stats:
couldn't figure out how to do that, but what's weird is if i build the app in Rider's release mode instead of VS release mode, i don't get those lag spikes
actually it seems like the lag only happens when the app runs standalone instead of being attached to VS/Rider... pretty weird
I would definitely get a perf trace if possible. If you can create a small stand-alone repro that would also help, since the behavior you are describing definitely should not happen.
So this could result in a github issue if there is an actual problem with the .net runtime.
I have the app on github if you want to try it out for yourself. I might just try and figure out how to disable WPF's auto scrolling while moving the mouse
GitHub
GitHub - AngryCarrot789/BCEdit180: A java class file viewer and edi...
A java class file viewer and editor, written in C#. Similar to jclasslib but supports extra features such as copy and paste bytecode between methods - GitHub - AngryCarrot789/BCEdit180: A java clas...
did you tweak GC?
although I'd follow mtreit's advice
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.