CODEWITHSUNDEEP
c++
Stewart
Stewart

Reputation: 613

Why does my program run way faster when I enable profiling?

I have a program that's running pretty slowly (takes like 20 seconds even on release) so, wanting to fix it, I tried to use Visual Studio's built in profiler. However, when I run the program with profiling enabled, it finishes in less than a second. This makes it very difficult to find a bottleneck. I would post the code but it is long. Are there any obvious or not so obvious reasons why this would be happening?

EDIT: Ok so I narrowed the problem down to a bunch of free() calls. When I comment them out, the program runs in the same amount of time that it does with profiling enabled. But now I have a memory leak :-/

Upvotes: 18

Views: 4244

Answers (7)

Kusal Dissanayake
Kusal Dissanayake

Reputation: 752

In my case it was due to the Windows Timer Resolution.

If you program uses threading, the System wide Timer resolution may be the reason for longer times when running through Visual studio.

The default windows timer resolution is 15.6ms

When running through profiler, the profiler sets this value to 1ms causing faster execution. Checkout this answer

Upvotes: 1

Shane
Shane

Reputation: 291

The reason is because when you run your application within Visual Studio, the debugger is attached to it. When you run it using the profiler, the debugger is not attached.

If you press F5 to run your program, even with the Release build, the debugger is still attached.

If you try running the .exe by itself, or running the program through the IDE with "Debug > Start Without Debugging" (or just press Ctrl+F5) the application should run as fast as it does with the profiler.

Upvotes: 29

Boolean
Boolean

Reputation: 14654

It could be due to few optimizations not being performed by the compiler when you run it in profiling mode. So, I suggest you check the parameters being passed and check the compiler documentation.

Upvotes: 0

Terry Mahaffey
Terry Mahaffey

Reputation: 11991

Use a non-intrusive sample profiler instead of an intrusive instrumented profiler.

Upvotes: 0

John Knoeller
John Knoeller

Reputation: 34188

turning on the profiler will end up moving your code around (a bit) which probably masking the problem.

The most common cause of hiesenbugs is unitialized variables, The second most common cause is using memory after it has been freed(). Since your free seems to fix it, you might think to look for late references, but I would still look for uninitialized variables first if I were you.

Upvotes: 5

Niki
Niki

Reputation: 15867

The general way would be divide-and-conquer, i.e. running only parts of the program and see when the problem goes away. But it sounds as if you already did that. AFAIK free usually doesn't take much time, but malloc can take a lot of time if memory is fragmented. If you don't call free(), the heap never gets fragmented in the first place. (intrusive profiling code might prevent memory fragmentation by allocating small data blocks and filling the free gaps - but I admit that's bit of a weak explanation).

Maybe you can add manual time measurement calls before/after the calls to malloc and new and print out the times to verify that? Maybe you can also analyze your memory allocation patterns to find out if you have a heap fragmentation problem (probably by looking at the code and doing some symbolic debugging in your head ;-)

Upvotes: 0

Drew Dormann
Drew Dormann

Reputation: 63912

That sounds a lot like a Heisenbug.

They really happen, and they can be painful to uncover.

Your best solution in my experience is to change how you are profiling -- possibly several ways -- until the bug disappears.

Use different profilers. Try adding timing code instead of using a profiler.

Upvotes: 10

Related Questions