Should I use FastMM in DLL as well?

0
votes

I have put uses FastMM in the dpr file of EXE which calls a DLL using LoadLibrary. So my question is should I put uses FastMM in DLL dpr project file as well?

I just want to maximize the performance gain by simply using a better memory manager e.g. FastMM in a multithreading application. I am also looking into alternative MM such as ScaleMM. The EXE is being invoked by a .NET application and the Delphi EXE calls the DLL (actually it is a COM+ dll) that does some floating point computation

I tried ScaleMM this afternoon and it turns out that ScaleMM uses more memory than FastMM4. Two unit tests failed because of 'Out of Memory' if using ScaleMM. However, with FastMM4 (version 4.991), there is no problem.

I didn't notice obvious speed gain using ScaleMM other than the 'out-of-memory' error. Thus I decided to revert back to FastMM4.

My question is, what is the benefit of using [shared memory manager] both FastMM4 in EXE and DLL (options, ShareMMIfLibrary etc)?

2
delphi
That depends on what you intend to do with the DLL. I don't think anyone can give you a yes or no answer with confidence. You'd have to provide more details. – David Heffernan
FastMM performs very badly in a multi-threaded scenario. And Delphi already uses FastMM, so adding FastMM won't change anything in terms of performance. If heap allocation is influencing performance, the best solution is to avoid allocating off the heap in hot spot functions. – David Heffernan
You'll get far better results by avoiding heap allocation in the first place – David Heffernan
Why have you not edited the question? – David Heffernan
@DavidHeffernan re-edited – justyy

2 Answers

2
votes

What is the benefit of using [shared memory manager] both FastMM4 in EXE and DLL?

The default memory manager is FastMM so there is nothing at all to be gained in terms of performance by using FastMM explicitly.

Whether or not a shared memory manager should be used depends on whether or not you are allocating in one module and deallocating in another. If so, you must use a shared memory manager. Otherwise it's a little pointless.

Whether ScaleMM has performance benefits depends on what your program does. We certainly cannot predict that.

My final comment would be that the best way to optimise anything is to stop doing it. Avoid the penalty of heap allocation by not doing it in a hot spot.

2
votes

Yes, you should and since FastMM is smart enough it will create common shared memory manager in the case you are going to use your memory manager from another memory managed Delphi application .

The FastMM adopted a principle that is very simple, Is to create a memory manager, Then the memory manager address into a process of all modules can read position, Such, Other modules before creating the memory manager, First check whether there are other module has the memory manager in this position, If you are using the memory manager, Otherwise, it creates a new memory manager, And will address in this position, Such, All modules in this process are the use of a memory manager, The shared memory manager.

So to recap, to use FastMM correctly(and with shared memory whenever possible):

  1. Open compiler options {$define ShareMM}, {$define ShareMMIfLibrary}, {$define AttemptToUseSharedMM}
  2. Add the FastMM unit as the first uses unit of each project files