9

When using the profiler in Visual Studio to track down expensive functions, I've seen on occasion that most of the work ends up being in [clr.dll]. That basically amounts to a black box, and I'm wondering if there's a way to track down why it's spending so much time there.

I assume that clr.dll handles stuff like JIT compiling, loading assemblies and managing appdomains, garbage collection, reflection, etc. But it makes it really difficult to actually tell what code is causing it to spend so much time.

Obviously it's some other code besides the runtime itself that is causing it to spend that much time in clr.dll, so how do you track down what code is at fault?

Bryce Wagner
  • 2,640
  • 1
  • 26
  • 43

2 Answers2

1

You need to know which part of your code - the code you can edit and compile, which is the only code you can fix - which part of that code is responsible for a substantial percent of time being used.

It does no good to know that clr.dll is using a lot of time unless you can tell which part of your code is responsible for it.

That information is in the call stack.

If you have a method, or even a single line of code, that is on the stack for some percent of time, such as 20%, then it is responsible for roughly that percent of time. If you could somehow eliminate that line of code (or make it take a lot less time) that 20% of the total time would become zero, or nearly so, giving you a speedup 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 it is pretty, unless the total results are appreciated. If it is applied repeatedly, large speedup factors are possible.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • For anything which is managed code, it does a really good job of tracking the entire call stack, it's just when it gets into native code that it loses track of what functions were responsible. So pausing it examine the call stack manually seems like it should give more useful results. – Bryce Wagner Jul 02 '12 at 13:27
  • @Bryce: 1) Yes, but I assume your code is managed code (unless it isn't), and if there's something you can fix, it's in *your code*. 2) The profiler collects stack information, but the problem is that rather than let you see what the stack samples are saying, they summarize into call trees & whatnot. That loses the information you need: the full understanding of what exactly is happening in particular samples, not in aggregate. – Mike Dunlavey Jul 02 '12 at 14:10
1

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

Doug
  • 321
  • 2
  • 5
  • Should be best answer, so far. In original question he is clearly already looking at profiler code lines and stack. – Beeeaaar Jul 20 '17 at 16:27