我也应该在 DLL 中使用 FastMM 吗？答案

【问题标题】：Should I use FastMM in DLL as well?我也应该在 DLL 中使用 FastMM 吗？
【发布时间】：2015-10-31 09:55:42
【问题描述】：

我已将 uses FastMM 放在 EXE 的 dpr 文件中，该文件使用 LoadLibrary 调用 DLL。所以我的问题是我应该把 uses FastMM 放在 DLL dpr 项目文件中吗？

我只想通过简单地使用更好的内存管理器来最大化性能增益，例如多线程应用程序中的 FastMM。我也在寻找替代 MM，例如 ScaleMM。 EXE 由 .NET 应用程序调用，Delphi EXE 调用执行一些浮点计算的 DLL（实际上是 COM+ dll）

我今天下午试用了 ScaleMM，结果发现 ScaleMM 使用的内存比 FastMM4 多。如果使用 ScaleMM，两个单元测试会因为“内存不足”而失败。但是，使用 FastMM4（4.991 版）则没有问题。

除了“内存不足”错误之外，我没有注意到使用 ScaleMM 的明显速度提升。因此我决定回到 FastMM4。

我的问题是，在 EXE 和 DLL（选项、ShareMMIfLibrary 等）中同时使用 [共享内存管理器] FastMM4 有什么好处？

【问题讨论】：

这取决于你打算用 DLL 做什么。我认为没有人可以自信地给你一个是或否的答案。您必须提供更多详细信息。
FastMM 在多线程场景中表现非常糟糕。而且 Delphi 已经使用了 FastMM，因此添加 FastMM 不会在性能方面发生任何变化。如果堆分配影响性能，最好的解决方案是避免在热点函数中分配堆外。
首先避免堆分配，您将获得更好的结果
你为什么没有编辑问题？
@DavidHeffernan 重新编辑

标签： delphi

【解决方案1】：

在 EXE 和 DLL 中同时使用 [共享内存管理器] FastMM4 有什么好处？

默认内存管理器是 FastMM，因此显式使用 FastMM 在性能方面没有任何好处。

是否应该使用共享内存管理器取决于您是否在一个模块中分配并在另一个模块中释放。如果是这样，您必须使用共享内存管理器。不然有点没意思。

ScaleMM 是否具有性能优势取决于您的程序的用途。我们当然无法预测。

我最后的评论是，优化任何事情的最好方法就是停止这样做。避免在热点中进行堆分配的惩罚。

【讨论】：

【解决方案2】：

是的，你应该这样做，而且由于 FastMM 足够聪明，它会在你打算从另一个内存管理的 Delphi 应用程序中使用内存管理器的情况下创建公共共享内存管理器。

FastMM采用了一个很简单的原理，就是创建一个内存 manager，然后把内存管理器地址变成一个进程的所有模块可以在创建内存之前读取位置，例如，其他模块 manager，首先检查是否有其他模块有内存经理在这个位置，如果你正在使用内存管理器，否则，它会创建一个新的内存管理器，并将在此地址 position,such,这个过程中的所有模块都使用一个内存 manager，共享内存管理器。

回顾一下，正确使用 FastMM（并尽可能使用共享内存）：

打开编译器选项{$define ShareMM}、{$define ShareMMIfLibrary}、{$define AttemptToUseSharedMM}
添加 FastMM 单元作为每个项目文件的第一个使用单元

【讨论】：

不是这么简单的。如果 DLL 将被不使用 FastMM 的主机使用，那该怎么办？
那么这是另一个故事，但我不认为OP在问这个，至少据我从问题中理解
好吧，我明白了，所以根据我的理解，您实际上可以在 HOST exe 和 DLL 中分别拥有两种不同类型的内存管理器？
是的，你可能有两个。