I am trying to get each performance counter value in C #.
So I used the PerformanceCounter class and checked the operation in debug mode, but although there were no errors or exceptions, it took almost 10 seconds to get the first time anyway, and I was a little worried.

When I erased all the breakpoints thinking that it would not change even if I removed the breakpoints, I was able to finish it in less than a second.

Applicable source code
var time1 = Environment.TickCount;
string value = String.Empty;
for (int count = 0;count! = 10;count ++)
        PerformanceCounter performanceCounter = new PerformanceCounter ("Objects", "Processes");// here
        value + = performanceCounter.RawValue.ToString () + ",";
var time2 = Environment.TickCount;
MessageBox.Show (value);
MessageBox.Show ((time2-time1) .ToString () + "milliseconds");

Specifically, at the beginning, I put a breakpoint only at the "here" part of the above code and confirmed it by step over.
When the breakpoint is executed, it takes about 10 seconds only for the first execution until control returns.
After the second time, it takes less than 1 second.

As explained above, when I cleared the breakpoint, a total of 10 times came back in less than 1 second.


Is it often the case that there is a large fluctuation in execution time with or without breakpoints?
If anyone knows why it is taking a long time to step over, I would be happy if you could give me some advice.


・ The development environment is VS2017 on Windows10.
・ Since the local performance counter is acquired, network delay should not be related.

  • Answer # 1

    There seems to be no answer,


    Is it often the case that there is a large fluctuation in execution time with or without breakpoints?

    If you think about what you're doing at the breakpoint, it's natural that it takes time. It was a little surprising that the delay occurred only the first time.
    I do not know the processing in Visual Studio, but if it is an embedded system, when a hard breakpoint comes to the corresponding location, a trap occurs and exception processing is performed. ->Naturally delay.
    Soft breakpoints replace the corresponding code with exception instructions. ->Naturally delay.
    In Visual studio, these processes are initialized at the first break, so it is estimated that it will be particularly slow, but it is only an expectation.

    Because debug mode contains unnecessary processing in these release modes, you should be prepared to be slow overall.