tags:

views:

159

answers:

3

Hi, Does FastMM makes your executables bigger? I notice my app grows about 300-500kb, which is rather big for me. I already turn off the delphi compiler option to exclude the debug info, but the size doesn't change.

I use the FastMM's FullDebugMode to on, is this affecting the size? But when I try to turn it off, it looks for libc, which I couldn't find.

Help please... I'm using D5

+7  A: 

First of all, it doesn't really matter. Programs compiled with that option aren't meant for general distribution. They're meant to help you find the problem so you can fix it and then ship a correct version of your program without the debugging options enabled.

Second, half a megabyte is only big if you still distribute on floppy disks. Whether that's truly much space depends on how big your program was beforehand. Compress your program when you distribute it, and you'll probably hardly notice the difference.

Finally, to the crux of your question, yes, full debug mode makes your program bigger. It should be obvious that enabling that mode adds more code. It adds the code that does all the debug checking, such as checking for heap corruption, generating stack traces, catching the use of freed interfaces, logging errors to a file, and logging memory leaks. It also adds code to load and use the full-debug-mode DLL, and it changes any assembler functions to be written in plain Delphi instead.

The compiler option about debug information should have no effect. It controls whether debug information is included in the DCU files; that information is always excluded from the EXE files (unless you're talking about TD32 debug information, but you shouldn't enable that anyway since you're not using Turbo Debugger).

If your program is looking for the Libc unit, then you did more than turn of full debug mode. You somehow turned on Linux mode. You're not using Linux, so don't turn on that mode. If you're stuck, replace your copy of FastMM4Options.inc with the original version and start over.

Rob Kennedy
Now I understand. Thanks for Rob! :)
AFF
500kb is an awful lot of code. fastmm is not that big? Many tools still use TD32 debug code btw, and IIRC it should be on for remote debugging too. IIRC even JCLDebug use(d?) it at some point for their tracebacks. So TD32 option is not just a historic artefct.
Marco van de Voort
I think it might be caused by a virus, I'll scan my pc.
AFF
+1  A: 

The FullDebugMode use a pure pascal version of the FastMM4 heap manager.

This version marks blocks, so that any memory leak will be tracked and reported.

But in all cases, it won't NEVER add 300-500 KB to your executable.

It will be slower than "normal" FastMM4 mode, because of the pascal version of the coding (less optimized than asm) and because of the extra checks performed (e.g. the blocks marking).

But the 300-500 KB executable size increase is NOT related to FullDebugMode. It's only a matter of some dozen KB (in worst case), because most of the used code stays in the external FastMM_FullDebugMode.dll library.

You should have changed by hand some Project Options, like the TD32 info or the remote debugging info. But these info are not required with FastMM4 in full debug mode, as far as I understand.

A.Bouchez
Thanks! I will look again, probably a virus.. I'll scan my pc
AFF
A: 

FastMM should compile with D5 and it shouldn't look for libc, which is Linux library. There's problem with latest versions when compiling under D5 (like this), try the latest source code from source repository?

Harriv
I removed the linux part and it works :)
AFF