0

I was profiling a big application programmed in.Net C# with dotTrace sampling mode and realized that there was an important difference of times between stopwatch measurement vs. dotTrace Sampling profiling. For example, if I measure only with the stopwatch, scenario lasts 78 seconds; however if I measure time when Sampling mode profiling is active, it lasts 87 seconds(I know there may be overheads like 2%-3%, but I got more than 10%). The scenario includes a file operation and some logical operations in total.

I also tried different dotTrace versions like 5.5.6 - 10 and 2016 versions, and the same results came up.

All measurements were made in same circumstances, and there was no different application or background service running.

Is there anyone got the same problem and an obvious reason or solution for this situation?

Thank for any help.

Riadh Belkebir
  • 797
  • 1
  • 12
  • 34
Oğuzhan Karaçakır
  • 1
  • 1
  • How do you measure the time? Taking samples also takes some time but it is not affects profiling result since dotTrace is clever enough to count only time spent in your code. – Kirill Jun 27 '16 at 13:36
  • I am measuring with stopwatch, start stopwatch when I click the button to start a function and stop when it ends. – Oğuzhan Karaçakır Jun 27 '16 at 13:39
  • I assume you are trying to find ways to speed up the code. After all, spending 78-87 seconds after clicking a button is enough time to be a bother. If that's your objective, rather than just curiosity about timing, there's another technique that's much more effective. [*Look here.*](http://stackoverflow.com/a/2474118/23771) – Mike Dunlavey Jun 27 '16 at 14:35
  • You understood wrong, my button does its job in 78 seconds but if profiling is started in Sampling mode, it takes 87 seconds. There is 9 seconds overhead caused by dotTrace. – Oğuzhan Karaçakır Jun 28 '16 at 04:45
  • @OğuzhanKaraçakır It is absolutely normal that your stopwatch gives bigger time with profiler because you measure not only the time spent in your code but also the time spent taking the samples. Look at the profiler report, it shows the same ~78 second, doesn't it? – Kirill Jun 28 '16 at 06:48
  • @Kirill I know it is normal that there is an increase because of profiling but the ratio is too high. And unfortunately, in sampling the duration is 87 seconds also. – Oğuzhan Karaçakır Jun 28 '16 at 06:53
  • @OğuzhanKaraçakır Again, it is the time of executing your code **plus** the time of taking samples. The duration of your code doesn't change in Sampling mode. Using stopwatch isn't correct in this situation, you need to look at the profiler output instead. Sampling mode doesn't slow down your code like other modes, it just pauses it for taking samples. So you get no overhead from profiler in profiling output although your program works longer. – Kirill Jun 28 '16 at 07:28
  • @Kirill I think I could not explain myself clearly. My function doSomething should spend less time than total time of the scenario, for example 78 seconds for this situation, however on the sampling, that method looks it spent 86,3 seconds in total. – Oğuzhan Karaçakır Jun 29 '16 at 08:53

0 Answers0