Visual Studio profiler how to track usage of [clr.dll]

Question

When using the profiler in Visual Studio to track expensive features, I sometimes saw that most of the work ends in [clr.dll]. It basically comes down to a black box, and I wonder if there is a way to track why he spends so much time there.

I assume that clr.dll handles things like compiling JIT, loading assemblers and managing application domains, garbage collection, reflection, etc. But it’s really hard to say which code makes it spend so much time.

Obviously, this is some other code besides the runtime itself, which makes it spend so much time in clr.dll, since you can find out which code is to blame?

Answer 1

You need to know what part of your code is code that you can edit and compile, which is the only code you can fix, which part of this code is responsible for a significant percentage of the time.

It is not good to know that clr.dll uses a lot of time if you cannot determine which part of your code is responsible for it.

This information is in the call stack.

If you have a method or even one line of code that has been on the stack for some percentage of the time, for example 20%, then it is responsible for about this percentage of the time. If you could somehow eliminate this line of code (or take a lot less time), then 20% of the total time will reach zero or almost so that will give you an acceleration factor of 1.0 / 0.8 = 1.25 or 25 %

So how do you find such lines? This is the method I use. No one claims that it is beautiful if you do not evaluate the overall results. If it is applied repeatedly, large acceleration factors are possible .

Answer 2

Based on my experience, this is probably in the GC. If you use LINQ, this is almost certainly in the GC. I recommend CLRProfiler to track Gen 0 spam.