Take the 2-minute tour ×

I was tasked to find out what's making part of an application I was assigned to so slow. I decided to give the trial of Redgate's Ants Profiler a go. When running it, the majority of hot spots were contained with loops that the original developer wrote as Parallel.For() loops.

Just to see what effect it would have, I replaced them with standard for-loops, and the profiler sped up by several seconds. However, testing without a profiler, using a simple DateTime.Now difference between the start and end of one such loop, shows that the Parallel.For() loop is more than twice as fast.

Is it possible that running the code through the profiler creates an artificial bottleneck when trying to use the Parallel class?

share|improve this question
The main purpose of a profiler is to find slowness bugs, not to be fast. –  Mike Dunlavey Jul 20 '12 at 13:45
@MikeDunlavey I realize this. The problem is that the program runs faster one with with the profiler, and slower without, creating a discrepancy that's dependent on the tool being used and not the bottlenecks in the code itself. It's like a false positive. –  KChaloux Jul 20 '12 at 14:17
add comment

1 Answer

up vote 1 down vote accepted

The problem is that when doing parallel things, the profiler samples all threads which makes the normal profiler performance drop be bigger with more threads.

share|improve this answer
News to me. I'll keep that in mind when looking at the profiler results in the future. Thanks! –  KChaloux Jul 20 '12 at 13:43
@KChaloux You may also want to make sure you are using less invasive Profiling Modes: if you do not necessarily need to see line-level times then switch to Method-level; if you only need to see you rown source code then set the appropriate profiling mode too. –  Dene B Jul 24 '12 at 11:00
add comment

Your Answer


