PDA

View Full Version : Memory manager's stack trace is making things wayyyyyyyyyyyyyyyyy toooooooooo slow



Etek
02-28-2012, 08:39 PM
Hi,

I haven't gotten to use your new SDK, I'm still using the old one. Don't know if you still use the same memory manager, but in case you do, I stumbled upon a problem with it and the hell if I know what triggered it.

On my Intel 2500K @ 4.2 GHz with Windows 7 64 home edition, 8GB RAM, Visual Studio 2010 Express, the stack tracer in memory manager slows memory allocation to such a degree that I can't do anything. As a comparison, running the release which doesn't use the memory mananger, things load up instantly, compared to waiting 10 minutes on debug and giving up.

The same project running on Windows XP on a 15" Macbook Pro, same Visual Studio 2010 Express, runs quite fine and I can do my work fine, but I'd rather work on my main machine.

I tried not using the stack trace and it behaves the same as the release version, (very fast), but no stack trace means no chance of figuring out where crashes occur...

Has anyone run into the same problem, or do you use another memory manager that's better?

Etek
02-28-2012, 08:52 PM
Just checked. In your new sdk, you are using the memmgr and beyond compare only shows a few comments added.
What the hell is going on with my machine.... :ninja:

Seth
02-28-2012, 10:51 PM
Hmm.

If built with MemMgr.cpp included it is *IS* very slow on my computer too.. for something like RTBareBones I wouldn't notice much but on say, my tank game, it means like 3 fps instead of 300+.

So I rarely include it except when I need to trace down mem leaks. (it's only purpose is to say "X bytes leaked from the new() in ..."

But even when I don't include it (most of the time), a crash in debug mode should give you a nice beefy stack trace.

Is the normal VS stack/debug stuff now working correctly?

Etek
02-29-2012, 09:45 PM
Oh I see. However, I need a custom allocator to hold my hand and spot leaks before they overwhelm everything.

I found this one. Let's call it tinymemmgr.h


#include <windows.h>
#include <crtdbg.h>

#ifdef __cplusplus
extern void* operator new (unsigned int size, const char* file , int line);
extern void* operator new[](unsigned int size, const char* file , int line);
extern void operator delete(void* ptr, const char* file , int line);
extern void operator delete[](void* ptr, const char* file , int line);
extern void operator delete(void* ptr);
extern void operator delete[](void* ptr);
#endif

#define NEW new(__FILE__,__LINE__)

#endif

and tinymemmgr.cpp



#include "tinymemmgr.h"

void* operator new(unsigned int size, char const * file, int line)
{
void* ptr = NULL;
if(size == 0) return NULL;

ptr = _malloc_dbg(size, _NORMAL_BLOCK, file, line);

if(!ptr) return NULL;

return ptr;
}

void* operator new[](unsigned int size, char const * file, int line)
{
void* ptr = NULL;
if(size == 0) return NULL;

ptr = _malloc_dbg(size, _NORMAL_BLOCK, file, line);

if(!ptr) return NULL;

return ptr;
}

void operator delete(void* ptr, char const * file, int line)
{
_free_dbg(ptr,_NORMAL_BLOCK);
}

void operator delete[](void* ptr, char const * file, int line)
{
_free_dbg(ptr,_NORMAL_BLOCK);
}

void operator delete(void* ptr)
{
_free_dbg(ptr,_NORMAL_BLOCK);
}

void operator delete[](void* ptr)
{
_free_dbg(ptr,_NORMAL_BLOCK);
}


Set this at the begining of main


_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

And this in the project settings under preprocessor _CRTDBG_MAP_ALLOC

I couldn't get it to work with regular new, so I had to use NEW instead... Oh well...