operator delete
-
Just to confirm if this is standard behaviour. I have a large linked list of some 100,000 objects, each allocated with new. When deleting this list, in debug mode it takes a good 15 seconds causing the app to appear hung. yet in release mode it takes a fraction of second. I know that with DEBUG set, a lot of extra validation is going on behind the scenes, but should it really cause this much of a slowdown?
Waldermort
-
Just to confirm if this is standard behaviour. I have a large linked list of some 100,000 objects, each allocated with new. When deleting this list, in debug mode it takes a good 15 seconds causing the app to appear hung. yet in release mode it takes a fraction of second. I know that with DEBUG set, a lot of extra validation is going on behind the scenes, but should it really cause this much of a slowdown?
Waldermort
yes. never trust a DEBUG version for performance.
Maximilien Lincourt Your Head A Splode - Strong Bad
-
Just to confirm if this is standard behaviour. I have a large linked list of some 100,000 objects, each allocated with new. When deleting this list, in debug mode it takes a good 15 seconds causing the app to appear hung. yet in release mode it takes a fraction of second. I know that with DEBUG set, a lot of extra validation is going on behind the scenes, but should it really cause this much of a slowdown?
Waldermort
Here is what happens when you call operator new when _DEBUG is defined. (As I understand it) 1.) _malloc_dbg() is invoked and your size_t is passed through. 2.) An object is created of struct type _CrtMemBlockHeader. 3.) The memory you have requested is allocated and memset() to 0xCD. (C = Clean) 4.) 4 bytes on both sides of the memory you requested are memset() to 0xFD (F = Fence) 5.) A pointer to the _CrtMemBlockHeader is added to an internal linked list for tracking. 6.) A pointer to the memory you requested is returned. When the memory is released here is what happens: 1.) _free_dbg is invoked and passed the address. 2.) The debug heap manager walks through the linked list and finds the pointer to the CrtMemBlockHeader struct. 3.) Checks are made on both sizes of the memory you requested to make sure the Fence 0xFD is still there. 4.) The memory location is memset() to 0xDD (D = Dead) 5.) The _CrtMemBlockHeader is marked as freed in the heap managers linked list. But the struct remains in memory. Upon application termination the entire linked list is walked and inspected for memory which was not freed or missing its fence. Hope this helps you, -Randor (David Delaune)
-
Here is what happens when you call operator new when _DEBUG is defined. (As I understand it) 1.) _malloc_dbg() is invoked and your size_t is passed through. 2.) An object is created of struct type _CrtMemBlockHeader. 3.) The memory you have requested is allocated and memset() to 0xCD. (C = Clean) 4.) 4 bytes on both sides of the memory you requested are memset() to 0xFD (F = Fence) 5.) A pointer to the _CrtMemBlockHeader is added to an internal linked list for tracking. 6.) A pointer to the memory you requested is returned. When the memory is released here is what happens: 1.) _free_dbg is invoked and passed the address. 2.) The debug heap manager walks through the linked list and finds the pointer to the CrtMemBlockHeader struct. 3.) Checks are made on both sizes of the memory you requested to make sure the Fence 0xFD is still there. 4.) The memory location is memset() to 0xDD (D = Dead) 5.) The _CrtMemBlockHeader is marked as freed in the heap managers linked list. But the struct remains in memory. Upon application termination the entire linked list is walked and inspected for memory which was not freed or missing its fence. Hope this helps you, -Randor (David Delaune)
That's a good description :) Now I can see why it takes so long, walking a linked list of 100,000 items must add quite an overhead. Another reason why delete was taking so long was due to using vld. Perhaps a mapped file may better suit my needs...
Waldermort