我已经在EXE的dpr文件中使用使用FastMM ,它使用 LoadLibrary 调用DLL。所以我的问题是我应该在DLL dpr项目文件中使用使用FastMM 吗?
我只想通过简单地使用更好的内存管理器来最大化性能提升,例如多线程应用程序中的FastMM。我也在寻找替代MM,比如ScaleMM。 EXE由.NET应用程序调用,Delphi EXE调用DLL(实际上是COM + dll)进行浮点计算
我今天下午尝试了ScaleMM,结果发现ScaleMM使用的内存比FastMM4多。如果使用ScaleMM,则由于“内存不足”而导致两个单元测试失败。但是,使用FastMM4(版本4.991),没有问题。
除了'内存不足'错误之外,我没有注意到使用ScaleMM的明显速度增益。因此我决定回到FastMM4。
我的问题是,使用[共享内存管理器] EXE和DLL中的FastMM4(选项,ShareMMIfLibrary等)有什么好处?
答案 0 :(得分:2)
是的,您应该并且因为FastMM足够聪明,所以如果您要从另一个内存管理的Delphi应用程序使用内存管理器,它将创建公共共享内存管理器。
FastMM采用了一个非常简单的原则,就是创建一个内存 经理,然后将内存管理器地址转换为所有模块的进程 在创建内存之前可以读取位置,这样,其他模块 经理,首先检查是否有其他模块有内存 经理在这个位置,如果你正在使用内存管理器, 否则,它会创建一个新的内存管理器,并将在此处解决 这样,这个过程中的所有模块都是使用内存 经理,共享内存管理器。
回顾一下,正确使用FastMM(尽可能使用共享内存):
mid | image | id
1 | m1 | 1
4 | m4 | 2
5 | m5 | 3
,{$define ShareMM}
,{$define ShareMMIfLibrary}
答案 1 :(得分:2)
在EXE和DLL中使用[共享内存管理器]和FastMM4有什么好处?
默认的内存管理器是FastMM,因此通过显式使用FastMM,在性能方面根本没有任何好处。
是否应该使用共享内存管理器取决于您是在一个模块中分配还是在另一个模块中解除分配。如果是这样,您必须使用共享内存管理器。否则它有点无意义。
ScaleMM是否具有性能优势取决于您的程序的功能。我们当然无法预测。
我最后的评论是,优化任何事情的最佳方法是停止这样做。通过不在热点中进行,避免了堆分配的惩罚。