Debuglog
Blitz3D Forums/Blitz3D Programming/Debuglog
| ||
| Hi! Does DebugLog generate any code when debugging is turned off? |
| ||
| Anyone? |
| ||
| I think it works the same, no matter the mode. M edit: if you want to exclude some code from release versions just put in a constant like DEBUG or something and then put the debug code into an if block that checks to see if it's true or false. It's my understanding that 'constant false conditions' are not compiled into the exe. |
| ||
| Debuglog doesn't write anything to the debuglog, when debugmode isn't active. |
| ||
| Right, but when I compile, does it generate code that checks to see if debug mode is on, or does the compile leave the code out entirely if debug mode is off at the time of compilation? |
| ||
| I imagine it does compile with debugmode on, but it won't write anything to the log. Check for yourself. Compile an exe that writes to the debuglog, and leave debugmode on. Run it and see if the program get slower :) |
| ||
| Looking for Slowdown might not be obvious. Can you use the old DOS file compare command on two versions of an EXE ? To compare original.txt and new.txt go to a command prompt and type: fc original.txt new.txt >difference.txt then simply read difference.txt to see what changed. So... put DebugOn.exe and DebugOff.exe into C:\temp and then at a command prompt use... fc DebugOn.exe DebugOff.exe >comparison.txt |
| ||
| I mean by writing to the debuglog every loop. Causes a big slowdown as the log grows. |
| ||
| If you compile in debug mode it will continue to generate debug info. If you turn it off before compile it wont. Simple as that. If debug mode is not active the log wont be either. |
| ||
| I'm not talking about whether or not the log is active. I want to know if there's any extra code generated into the .exe. Will try the file compare thingy... |
| ||
| Great. Even without changing any code the debug enabled version and disabled versions are different... The program is just a single print statement. And the dir command lists the two as the same size. I gather this is because DOS is reporting the filesize as the number of bytes-per-sector * sectors, even though that last sector isn't full. |
| ||
| Well, the Debuglog becomes inactive so it's reasonable to assume there is no code generated. Can we be sure? I suppose not. So let's try a quick test. DebugLog "one" DebugLog "two" Stop Create an exe with Debug mode turned off. Check the file size. Now comment out one of the DebugLog lines and try again. File size is exactly the same. This shows that there was no DebugLog code. The remaining reference to DebugLog guards against the possibility the compiler doesn't generate code if DebugLog is never used. I don't think Blitz does this sort of optimization, but it can't hurt to be paranoid. |
| ||
| Okay, got it. I made a 90K file, with just loads of debuglog "woops" lines. The .exe with debug mode on is 1.84 meg, 1.59 meg without it on. But a program with one print statement is 1.18 meg. So debuglog DOES generate code, even with debug mode turned off. |
| ||
| Hmmm... that's unexpected. Okay, compile a bunch of DebugLog "woops" statements, with debug mode off. Next, rename the .exe file to .txt and open it in WordPad. I see a long list of repeated woops, which I guess is a table of string literals. There is a similar repetition of _fdebuglog, apparently corresponding to the DebugLog statement. |
| ||
| Not really unexpected. I imagine the debuglog command is written with a line at the start along the lines of ... if( debugmode == off ) return; Seems logical enough. If it really bothers you, use the preprocessor that's floating around and #ifdef it out. |
   |