Making Debug run faster.

[ThuGie]

Hey,

For another project that I'm helping with its quite a problem that debug is slowing the application down as much as it does.

I read around the internet that using _NO_DEBUG_HEAP=1 could fix that.
Now i tried it out but notice the memory being the same and the loading also.
Haven't tried it on a full run yet.

Release mode gives 74mb ram debug mode uses 450mb ram.
Adding _NO_DEBUG_HEAP gives no change to this.

The loading takes just as long etc so i figured _NO_DEBUG_HEAP simply isn't working for some reason.
I used google quite a bit but they say add it as a system env i did no change.
So I'm hoping there is another option or a reason why it inst working.

The goal is to make the application run quite a bit faster then it currently does in debug.
As atm even the cpu is a bottleneck as when running in release only a bit of cpu is used but in debug mostly around 60%.. what is a bit much more so when more connections are made.

[FakeTruth]

Running without the debugger should already speed the program up (run with CTRL+F5 ), though this beats the purpose of having debug mode.

Debug mode is also slower because it's not optimized, if you turn on optimizations the debugger might not be able to break on the correct lines in code because some code may have disappeared or rewritten.

Long story short:

[xoft]

I'd say the debyg crt is your main problem, especially if your app is multithreaded. I think you can actually use release crt with a debug build, but basically you'll be losing all kinds of debugging measures implemented in the debug crt, not only memory debugging, but also (off my memory) iterator-to-container checks, function calling conventions checks.
If you're sure you want to do this anyway, toggle your project's Runtime Library option on the "C/C++ -> Code Generation" page in the Project properties dialog. I suggest You first create a new configuration for this and leave your Debug cofiguration unchanged, in case you still need it or if something goes wrong.

Still, such a difference in performance usually means you're not using stuff the right way. Such as using the wrong kind of containers for your algorithms.
For a recent example, see MCS rev 368 - the conversion was initially using std::string and pushing data into it byte by byte. Reserving the memory beforehand didn't help much, but using a plain old fixed-size buffer did the job - simply because pushing a byte to the string meant a whole swarm of various tests done by the debug CRT and then serializing access to the string via a critical section - try do that 100k times

[ThuGie]

Ah yeah i see what your saying,
Well the other reason i wanted to do _NO_DEBUG_HEAP
Because in release the application messes up crashes more often in debug this is not the case.

As FakeTruth explained me before its because in debug bigger space is added between everything in memory.
So less chance of it overwriting something if it go's outbounds. i thought _NO_DEBUG_HEAP would remove that big space.
So i might actually get the same problem in debug and it would make the server crash so i can find where it screws up.

As atm i simply have no clue..
And i didn't write the code so i might have to check some stuff :p.
but here's a bit of info its a server app.
Multi threaded doesnt seem to lockup anywhere.

all threads have a while loop with a small sleep in it.
in those while loops it mostly loops tru all connections a few times.
like one to see if new packets are arrived etc.

But i need to find where the problem lies of what is overwriting memory, out of bounds.. as it doesn't trow a error or anything.
If i can fix this i can probably run it normally in release without many problems.

Edit:
Btw running it without a debugger attached doesnt seem to make any differents..
Unless that only affects cpu load and not memory. as atm as i run it local i can only see a differents in memory for 1 player for 74mb release mode, 400+mb debug mode.
that doesnt change when running it without debugger attached. so i asumed it didnt work and the cpu wouldnt drop as well.

[xoft]

I'd say if your app crashes, then you have a problem much more serious than memory-hogging There are probably bugs in the memory handling involved.

[FakeTruth]

Actually if you manage to remove the extra space in Debug, and it'll crash, you probably get some useless information from it anyway.

It would probably crash due to the effects of writing outside array bounds instead of the actual writing outside bounds. These effect can possibly be noticed only after an hour of the overwriting.

You see, you might have two arrays

Code:

int Array1[256];
int* Array2[64];

The first array is a list of integers, the second is a list of pointers to integers. Now if you do this it would probably overwrite Array2:

Code:

for( int i = 0; i < 64; ++i ) // Inside bounds of both Array1 and Array2
  Array2[i] = &Array1[i]; // Maps Array1 values to Array2
for( int i = 0; i < 256+64; ++i ) // This goes out of bounds of Array1 and randomize the entire Array2
  Array1[i] = rand();

Probably no crash so far!
But an hour later you're doing this.

Code:

for( int i = 0; i < 64; ++i )
  Array2[i] += 100;  // CRASH!

The point where it crashes still doesn't give you any indication about what happened to Array2

[FakeTruth]

Ah yeah i see..
So how do i go about finding where its causing the problems ?
Without overlooking all the code and testing it piece by piece..

By removing pieces of code until it no longer crashes, and then narrow down your search

[FakeTruth]

Perhaps you can loop all arrays in the program and check if they're valid once every second or so

[FakeTruth]

Perhaps, I dunno

[xoft]

You might want to start small - use _CrtSetDbgFlag() first, it may give you some results and you don't need to buy overpriced solutions
http://msdn.microsoft.com/en-us/library/...s.90).aspx
Try setting _CRTDBG_CHECK_ALWAYS_DF. Your program will be really slow, but it is likely to catch memory errors relatively close to their source.