How to remove FastMM497 from my project file?

After spending a week of my time running using FastMM on my project file, I now have completely gone through my program and to best of my knowledge remove all but 3 error messages raised by FastMM497. Now, I want to remove FastMM from my program and run without it. Can I do that? If I remove it and run my program, will my program start leaking memory? To best of my knowledge I have removed and changed my project option setting back to the way it was before.

However, I 开发者_Go百科did notice that my program is a lot bigger in when I run the executable file. Originally, my program used to be around 5,000KB to 6,000KB when it starts up. After working through FastMM, now it is around 21,000KB in the Task Manager. Am I looking at this correctly?

Can I just leave FastMM497 in my program and deploy it as is to my users?

Well, I think you should leave the full version of FastMM around because presumably you will continue developing your program and you may inadvertently introduce more memory leaks. Having FastMM to tell you about these helps.

However, what you don't want to do is release to your users a version using the FastMM debug options. This is much slower and consumes much more memory, and also reports diagnostics which you presumably don't want your users to see.

What one normally does is have two build configurations, DEBUG and RELEASE. When you build DEBUG you have all the diagnostics options. When you build RELEASE you switch that all off. You would typically configure it through conditional defines which control settings in the FastMM include file, FastMMOptions.inc.

The way I configure it is that the DEBUG configuration defines a condition called UseDebugFastMM and the RELEASE configuration does not. Then in FastMMOptions.inc I respond to that conditional by enabling all the debug features if it is defined.

Having said all that, what I actually release to my clients does not use FastMM at all because I find it doesn't perform terribly well under thread contention. Instead I use a custom memory manager that simply delegates to the malloc() to be found in msvcrt.dll which I find performs better. But it's all controlled with conditionals and it's well worth getting the project well configured so that you can easily experiment if you need to.