如何从我的项目文件中删除 FastMM497?

发布于 2024-10-26 15:01:43 字数 349 浏览 1 评论 0原文

在我的项目文件上使用 FastMM 运行了一周之后,我现在已经完全浏览了我的程序,并且据我所知,删除了 FastMM497 引发的除 3 条错误消息之外的所有错误消息。现在,我想从我的程序中删除 FastMM 并在没有它的情况下运行。 我可以这样做吗?如果我删除它并运行我的程序,我的程序会开始泄漏内存吗?据我所知,我已删除项目选项设置并将其更改回之前的状态。

但是,我确实注意到,当我运行可执行文件时,我的程序要大得多。原来,我的程序启动时大约有5,000KB到6,000KB。经过 FastMM 处理后,现在任务管理器中的大小约为 21,000KB。我对这个的看法正确吗?

我可以将 FastMM497 留在我的程序中并将其按原样部署给我的用户吗?

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 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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

裂开嘴轻声笑有多痛 2024-11-02 15:01:43

好吧,我认为您应该保留 FastMM 的完整版本,因为您可能会继续开发您的程序,并且可能会无意中引入更多内存泄漏。让 FastMM 告诉您这些会有所帮助。

但是,您不想做的是向用户发布使用 FastMM 调试选项的版本。这会慢得多并且消耗更多内存,并且还会报告您可能不希望用户看到的诊断信息。

通常所做的是有两种构建配置:DEBUG 和 RELEASE。当您构建 DEBUG 时,您拥有所有诊断选项。当您构建 RELEASE 时,您将其全部关闭。您通常可以通过条件定义 FastMM 包含文件 FastMMOptions.inc 中的控制设置来配置它。

我的配置方式是 DEBUG 配置定义了一个名为 UseDebugFastMM 的条件,而 RELEASE 配置则没有。然后在 FastMMOptions.inc 中,我通过启用所有调试功能(如果已定义)来响应该条件。

话虽如此,我实际向客户发布的内容根本没有使用 FastMM,因为我发现它在线程争用的情况下表现不佳。相反,我使用一个自定义内存管理器,它只是委托给 msvcrt.dll 中的 malloc(),我发现它的性能更好。但这一切都是由条件控制的,并且非常值得对项目进行良好配置,以便您可以在需要时轻松进行实验。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文