SapMM did work fine for simple tests.
But after trying SapMM with our regression tests, it sounds like if it just crashes (just like SynScaleMM by the way), when it reaches the inteface-based service level.
IMHO this is not due to our own code, since when running memory-proof tools (like FastMM4 in full debugg mode), no corrupted block is identified.
We found out that only FastMM4 and ScaleMM2 are able to run all our regression tests (more than 14,000,000 individual checks, including a whole test coverage of our framework, in about 20 seconds!).
Sounds weird and disappointing. SapMM may not be as stable as expected - it is at the level of SynScaleMM, not a true alternative to FastMM4.
ScaleMM2 works pretty good, even if it eats a lot more memory than FastMM4, when we reach the multi-thread part of the regression tests (a threadpool of 50 threads is created several times for those tests, and at this level, global memory use of the process just raised up).
FastMM4 is still a good alternative, even in multi-threaded environment, since mORMot code patterns tries to limit memory allocation as much as possible, so contention is reduces as much as possible.
Do you remember this former article about scalability of the Delphi memory manager, in multi-thread execution context?
Our SynScaleMM is still experimental.
But did pretty well, for an experiment!
At first, you can take a look at ScaleMM2, which is more stable, and based on the same ground.
But a new multi-thread friendly memory manager for Delphi just came
It is in fact the anonymous (and famous) "NN memory manager" Primož talked about in his article about string building and memory managers.
(Note that in this article, our SynScaleMM was found to be scaling very well, but on the other hand, Primož did compile its benchmark program in Debug mode, so our
TTextWriter was not in good shape:
when you compile in Release mode, optimizations and inlining are ON,
and our good
TTextWriter just flies... See the note at the
beginning of the article - this is why I never find those benchmarks very
informative. I always prefer profiling from the real world with real useful
process… and was never convinced by any such naive benchmark.)
( these simple concatenation tests did not show up any instability problem of SapMM - alias NN - whereas our own mORMot regression tests were much more demanding - because closer to real use case. It won't help convincing me that such a naive benchmark would be very indicative and meaningful...)
OK, back to our business!
SapMM is an interesting beast.
Sounds like if Alexei (the initial coder) has a C coding background. But
that's fine when you have to deal with low-level structures and algorithms, as
required by a memory manager.
It features everything we may ask for such a piece of code: clear design, optimized code (mostly by inlining process), memory leak reporting, some parameters for tuning.
It is only for Delphi XE (and up) under Win32 by now, but contributors are
It is used in production since more than half a year, and it passed all FastcodeMM benchmark tests.
If you want a direct link of the today's source code, without SVN, you may
try this direct link from
(but it probably will never be updated - you are warned)
You could take a comparison with the Memory Manager embedded with the
It has also a per-thread heap, with another implementation design. And it is now pretty stable and cross-platform!
It uses some nice FPC compiler tricks, like a
which is quite unique and powerful when dealing with such low-level stuff like
a memory manager.
The FPC guys did great job at the compiler level, and they do not forget to optimize the RTL in their work, which is pretty reassuring for the future - do you follow my mind?