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

Question

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, whe

Answer 1

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.

Answer 2

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

Answer 3

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 ;-)

Answer 4

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.

Answer 5

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.

Answer 6

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.