🔒 Locked

Proggy VERY Slow in Debug

Started by DudeMiester Oct 29, 2004 at 10:04 PM 4 replies 1.8k views

Original Post

Oct 29, 2004 at 10:04 PM

I know debug mode always makes your program run slower but this is ridiculous, my program is running about 100x slower! I know what the source of the problem is, but I don't know why it's cause such a huge slowdown. Basically, I have a memory manager and within it, I represent units of data allocated on the heap by an abstract representation called CDataObject. Now in order to have proper deletion, this class has a function pointer to a function that contains the data's type and array/not array information. It is assigned by my smart pointer class when a piece of data is created an assigned to one. It sorta looks like this:


template<class Type>
void DeleteData(void* Data)
{
    delete (Type*)Data;
}

template<class Type>
void DeleteArray(void* Data)
{
    delete [] (Type*)Data;
}

class CDataObject
{
    void (*varDelete)(void*);
    .....
};

So when the smart pointer, which is template class and there is an array and non-array version, gets a piece of newly created data it sets the appropriate function to the CDataObject's function pointer varDelete. Then when the garbage collection cycle determines the data needs to be deleted, it just called the function pointer passing the data's address. Now when running in normal mode it's very fast, but in debug ludicrously slow. Any reason why, and any ways I can improve my memory manager to prevent this?

Andrew Russell

Oct 30, 2004 at 8:12 AM

Hrrmn...

I'd suggest going so far as to being able to #ifdef your memory manager out completly, and then do so for debug builds (although if you use it, try turn it off and test every so often). On a project I helped write a memory manager for, we overwrote the new operator, which made this easy on us, but you could probably do it to with a little work (or make a "does nothing interesting" memory manager).

On this same project, the memory manager had unexpected results. Our test cases were sped up by some crazy ammount, but when we tried it in an actual project, we found it slowed things down. So being able to remove it seamlessly turned out to be a very good thing.

And of course - be sure it's the source of your problem - run a profiler.

iMalc

Oct 30, 2004 at 3:18 PM

You say you know that your memory manager is the problem, but in getting help it's best to say that there is a problem and provide the necessaries for others to make their own conclusions. Often, the reason you can't solve something is that your own conclusions aren't totally correct.

That said, you haven't given enough info to do anything more than make a rough guess what the cause is.

I personally wouldn't ever rely on a garbage collector to clean up for me. Better to do it yourself if you can.

Archi

Oct 30, 2004 at 7:19 PM

Quote:
Original post by DudeMiester
Now when running in normal mode it's very fast, but in debug ludicrously slow. Any reason why, and any ways I can improve my memory manager to prevent this?

Make sure you're not reading anything from disk.
Make sure you're not writing anything to disk.

DudeMiester

Oct 31, 2004 at 12:42 AM

Yeah, later on I realized it was just the cumilative effect of delete in debug mode being slower. You see I was stress testing the system by making 3x3 matricies, and then getting a 2x2 submatrix 10,000,000 times. This created a 4 float array each time using new, which of course had to be deleted after. Now I can see how deleting 10,000,000 objects could be slow. Interestingly though it was very fast outside of debug mode. Still I relised using new to create the array for my matrix class wasn't a very good idea, because I get about a 10 time speed up without it in normal mode, and about 1000x speedup in debug. lol.

Oh and as for stability with it. I basically generate a dependancy graph of the data as data is created, and I use that during garbage collection to determine any isolated data that therefore must be deleted. So it's impossible for it delete anything it's not supposed to. Even if you don't follow the correct procedure for setting up classes using the memory manager it still can't screw things up because all data defaults to root data that can only be manually deleted.

silvermace

Oct 31, 2004 at 3:22 AM

Quote:
Original post by DudeMiester
Yeah, later on I realized it was just the cumilative effect of delete in debug mode being slower. You see I was stress testing the system by making 3x3 matricies, and then getting a 2x2 submatrix 10,000,000 times. This created a 4 float array each time using new, which of course had to be deleted after. Now I can see how deleting 10,000,000 objects could be slow. Interestingly though it was very fast outside of debug mode. Still I relised using new to create the array for my matrix class wasn't a very good idea, because I get about a 10 time speed up without it in normal mode, and about 1000x speedup in debug. lol.

Oh and as for stability with it. I basically generate a dependancy graph of the data as data is created, and I use that during garbage collection to determine any isolated data that therefore must be deleted. So it's impossible for it delete anything it's not supposed to. Even if you don't follow the correct procedure for setting up classes using the memory manager it still can't screw things up because all data defaults to root data that can only be manually deleted.

duuuuude, memory fragmentation anyone??? :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.