Is the .NET garbage collector less aggressive when releasing an assembly with debug symbols?

In .NET 4.5, we configured our assemblies to create debugging symbols for the Release assembly - to help debug crash dumps, etc. on customer sites.

My question is: without a debugger connected and working normally during the production process, does the presence of debugging symbols indicate that the garbage collector behaves differently?

I recently read the following in an e-book:

β€œEach of these assemblies will be combined with debugging symbols, which will lead to lower performance, which means that the GC will not work as efficiently as in the release build. In essence, the GC will be less aggressive in recovering memory when debugging symbols are turned on "Since debugging symbols are enabled, the GC must be prepared for the debugger to be attached, and many of the rules for identifying unreachable links may not apply. With a debugger connected, many more objects can be reached."

It's true?

+4
source share
1 answer

What you are reading refers to code compiled in debug mode or, to some extent, code running with the debugger attached. The presence of debugging symbols is only a side effect of compilation in debugging mode, the debugging symbols themselves do not change the behavior.

The garbage collector extends the lifetime of variables in debug mode from using a variable to a variable. This is based on the presence of a debugger, not on the presence of debugging symbols.

+1
source

Source: https://habr.com/ru/post/1488527/


All Articles