Release build in Visual Studio Ctrl+F5 10x slower than from outside VS

Question

I have a medium-sized native C++ application. When I run it from within Visual Studio (2008), it runs roughly 10x slower than when run from outside Visual Studio. This applies to both Debug and Release builds, and happens both when I run the application as Start Debugging (F5) and Start Without Debugging (Ctrl+F5).

In other words: Running a Release build in Visual Studio without a debugger is 10x slower than running the same executable from a command prompt (or from Windows Explorer).

Things I tried:

• Double-checking no breakpoints, tracepoint, exception debugging etc. are set. There were none.
• setting _NO_DEBUG_HEAP=1 in VS Debugging properties for the app. No effect.
• Setting cmd /c set PATH to be run by Ctrl+F5 instead of the app itself and comparing that to the PATH available outside of VS. No difference.
• Running DependencyWalker on the exe and comparing it with libraries Visual Studio lists as loaded when running the app. No difference.
• Googling and searching SO, but this only came up with the above ideas or dealt with F5 vs. Ctrl+F5 differences (there are none in my case).

I've run out of ideas, and I would be grateful for any pointers on where to look or what to try.

The application uses OpenGL an Qt, and does fairly ordinary stuff: no loading/unloading DLLs, file input at start only (3D model and shaders), no file output, few 3rd party librairies (and apart from Qt, all are linked statically).

To add insult to injury, I only started experiencing this behaviour after a recent internal refactoring of the app. Before that, it ran fine both within and withot VS. This refactoring involved mainly extracting some functionality into a newly created base class (that is, changing A > B inheritance into A > C > B inheritance, very few virtual calls involved) and replacing a few new[] calls with std::vectors.

EDIT

I tried one more thing: In the Debugging properties of the app, setting the target to be cmd /k, then doing Ctrl+F5 to launch the cmd and running the app from that command line. This way, it runs at normal speed (i.e. the 10x slowdown is not there). This is useless for debugging, of course, but I wanted to mention it out of a sense of completeness.

EDIT 2

I've found it: it was a weird dependency on working directory. If started from the directory where the .vcproj resides (which VS normally does with F5 and Ctrl+F5), a relative path in the directory would exist and a debugging output (whose existence I had forgotten) succeeded, slowing down the run. Executing from any other directory made the output fail, resulting in faster execution.

My apologies to all who spent their time on this. Voting to close.

Answer 1

From my experience, it is related with Low-fragmentation Heap. But you said you have set _NO_DEBUG_HEAP=1, so I don't know if this is the right answer, I think you at lease can give a try.

The low-fragmentation heap (LFH) helps to reduce heap fragmentation, when enabled, it can boost the performance of your application with 10X speed increase if your application use a lot of memory allocations.

LFH is enabled by default starting with Windows Vista, however, LFH is disabled When a process is run under any debugger, certain heap debug options are automatically enabled for all heaps in the process. These heap debug options prevent the use of the LFH.

This explains why the application runs 10x slower if launched from VS.(I encountered the same problem in the past). you can use the function HeapQueryInformation to the get heap information and output it to verify if it is caused by LFH disabled.

For details of LFH, refer these two articles:

1. Low-fragmentation Heap
2. HeapSetInformation function

One similar post on the forum: Why does my STL code run so slowly when I have the debugger/IDE attached?