CODEWITHSUNDEEP
c++qtdebuggingmemory-managementvisual-studio-2013
Silicomancer
Silicomancer

Reputation: 9196

Freeing memory very slow with Visual debugger

In our applications we are using a class that utilizes a lot of big Qt containers. If objects of that class are destroyed while a Visual Studio debugger is attached to the process, freeing of the memory is extremly slow (multiple minutes). Still it works fine but simply very slow.

Some time ago I already could confirm that the debugger's memory checking is reponsible for this. It is a known issue.

I worked around this issue by simply stopping the application by debugger if it is stuck in freeing memory or by starting it without an attached debugger.

However now I need to debug code that periodically deallocates such objects. Of course it works but it is inacceptable slow and since I need to do a lot of cycles I need a better solution.

Is there any way to disable heap memory checking in VS2013 debugger? Or is there a way to exclude some variables from those checks?

Upvotes: 3

Views: 798

Answers (2)

Silicomancer
Silicomancer

Reputation: 9196

I tried another solution. Setting the environment variable _NO_DEBUG_HEAP to 1 actually solves my problem.

This can be done on system level (using a common environment variable editor e.g. REE) or on application level by setting the Visual Studio project property Debugging/Environment to "_NO_DEBUG_HEAP=1".

I found this information in an answer to my question that unfortunately isn't visible anymore (I suppose it was deleted by moderators). It contained this link that was actually very helpful.

Upvotes: 3

Adrian McCarthy
Adrian McCarthy

Reputation: 48019

_CrtSetDbgFlag controls what kinds of checking the debug heap does.

It's possible your code (or perhaps a library you're using) has cranked up the checking level. For example, you can have it check the integrity of the heap on every allocation and deallocation. That can cause a huge slowdown. Don't use _CRTDBG_CHECK_ALWAYS_DF unless you actually need it to find a specific memory problem.

For basic leak checking, which generally isn't a huge performance penalty, you need only (_CRTDBG_LEAK_CHECK_DF | _CRTDBG_ALLOC_MEM_DF).

Upvotes: 2

Related Questions