You've got a great profiler tool, I'm very happy with it. Here is a question:

I run my task under profiler and it reports for example 38 seconds to complete in the CPU statistics. I can of course start looking at the methods that take longest and are invoked most often, this stuff is okay.

The Garbage Collection view shows Time Spent in GC at around 80%. Well on some test runs it actually almost pins at 100%.

Does it mean that 80-100% of the 38 seconds spend on running the whole task are spent doing the Garbage Collections?

The application currently is quite memory intensive I think. The CLR heap reaches 400+mb and tons of objects are created during the task. But I really want to understand that Time Spent in GC means in your profiler.

The time spent in GC percents is an estimation. It allows to understand whether the garbage collector's amount of work is significant for the application's performance. If at some point you see that there was 80% spent in GC, that means that in some time range 1-2 seconds long CLR was doing GC 80% of that time range, and was not doing it 20% of that time, instead running application threads or being idle.

It is similar to what Task Manager shows for CPU usage: if you see 80 % CPU usage, that means that during some short time range CPU was performing some work 80% of time and idle 20% of time.

Whether the overhead is big or not, depends on your task. You should decide yourself whether the GC pauses are acceptable or not.

Thanks. Just let me talk it though once again and correct if I'm wrong anywhere.

I have only one thread. There is no UI. Consider it is just a complex computational task. Just simple work from start to finish.

If GC shows almost steady 80% it means CLR was going GC 80% of time in every interval. This means that my thread was put to wait and as a result only worked 20% time of those intervals. That means really excessive GC. I am not happy that I wrote code that is only given 20% of thread time because CLR is too busy cleaning up after it.

Since there is no UI I cannot feel any GC pauses. I run the task and it takes 38 seconds to complete. Is it likely that if I dramatically reduce the amount of work for GC, then I can get close to 8 seconds (20% of 38 sec) to complete the same task?

Just a thought. If the above is true (I mean 80% GC and 20% useful time), then why your CPU profiling data does not give me any indication that the problem is not in the time spent in my code, but the delay is from the time spent in GC code? It would be nice that say in the Hot Spots view for CPU Profiling I would see .NET GC methods at the top (that take 80%), not my methods that probably work fast enough (all of them take 20% only).

Thanks. Just let me talk it though once again and correct if I'm wrong anywhere.

I have only one thread. There is no UI. Consider it is just a complex computational task. Just simple work from start to finish.

If GC shows almost steady 80% it means CLR was going GC 80% of time in every interval.

Yes.

This means that my thread was put to wait and as a result only worked 20% time of those intervals.

Yes.

That means really excessive GC. I am not happy that I wrote code that is only given 20% of thread time because CLR is too busy cleaning up after it.

It really depends on used algorithms. For example, even if it is possible to use another algorithm which does not create that many temporary objects, it does not necessarily have to be faster than the combination of the old algorithm + GC work time.

Since there is no UI I cannot feel any GC pauses.

Let's say "time spent in GC" instead.

I run the task and it takes 38 seconds to complete. Is it likely that if I dramatically reduce the amount of work for GC, then I can get close to 8 seconds (20% of 38 sec) to complete the same task?

Please see above. All depends on whether the new algorithm will work faster than the old one + GC.

The good news is that often sources of excessive garbage allocation are rather bugs or caused by inaccurate coding, and thus can be easily eliminated.

So, please perform excessive GC profiling to see what is the source of that problem.

Just a thought. If the above is true (I mean 80% GC and 20% useful time), then why your CPU profiling data does not give me any indication that the problem is not in the time spent in my code, but the delay is from the time spent in GC code? It would be nice that say in the Hot Spots view for CPU Profiling I would see .NET GC methods at the top (that take 80%), not my methods that probably work fast enough (all of them take 20% only).

Do you mean adding something like "GC pauses" nodes to the views showing top methods? Technically, GC pauses are not methods, it's just a state of CLR when it does some internal work. But from presentation point of view, perhaps it is good to show that work alongside "real" methods.