Page 1 of 1

Slow while profiling

Posted: Fri Feb 17, 2006 10:21 am
by Kieron
Hi, I'm profiling a process that takes anywhere upto 30minutes to complete. It is rather heavy on the CPU at the best of times, but while profiling it can take up to 7 1/2 hours to complete. Does this sound right or is something else causing the profiling to run so slow.

Posted: Mon Feb 20, 2006 8:19 am
by Andreas Suurkuusk
The profiler will slow down the profiled application. How much the application is slowed down depends very much on what the application is doing. An application that performs a lot of allocation can be substantially slower when run under the profiler, especially when the allocations are short lived. So when profiling an application that performs a lot of allocations, it is possible that it will take 15 times as long to run.

There are some settings you can change to increase the performance of the profiler. Disabling real-time collection (by deselecting "Collect realtime data" in the Settings dialog) will probably affect the performance the most. Other things you can try is to disable root referee identification (only affects the performance under .NET 1.x), and heap utilization tracking. Enabling delayed instance cleanup will also in many cases improve the performance of the profiler.

Below is a short list of things the profiler performs that will slow down the application:
  1. Each time a class instance is allocated, the profiler must save information about the allocation. This information includes the class, the call stack of the allocation, the thread etc. The runtime, on the other hand, can allocate an instance extremely quickly; an allocation is more or less only an addition.
  2. Whenever a GC is performed, the profiler needs to update the locations of surviving instances (in case they have been moved) and it must cleanup information about instances that have been GCed. If real-time tracking is enabled, the profiler will also walk all references, in order to find out which instances are reachable. The runtime can optimize the walking of references significantly when a lower generation GC if performed, and it does not have to perform any "cleanup" of GCed instances.
  3. The profiler also has to keep track of the call stack at all times. This adds a slight overhead to all method calls, but should not create to much overhead unless the methods are very short.

Posted: Fri Feb 24, 2006 9:53 am
by Kieron
Thankyou, I'll try those.