The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,837 other followers

Archive for the ‘FastMM’ Category

Delphi memory allocators and configuration notes in multi-threaded environments with high allocation/deallocation rates

Posted by jpluimers on 2020/02/20

From an interesting discussion at [] FaceBook: Delphi developer thread by Jarto Tarpio with some measurements by Jarto Tarpio and André Mussche.

  • Manipulation of strings and lists in Delphi have high memory allocation/deallocation rates, so HTTP related services with high call rates are affected more than regular services
  •  FastMM:
    • conditional defines that can help are NeverSleepOnThreadContention, UseSwitchToThread, and UseReleaseStack then measure.
    • has one huge advantage: It’s very, very good at keeping memory fragmentation at bay
    • default settings are for applications that use lots of CPU, but have no really high memory allocation/deallocation rates
    • has very good debugging facilities
    • Under FullDebugMode address space is never released back to the operating system so once the address space has been exhausted there is very little room to manoeuvre.
  • TCMalloc:
    • is very good at multi-threaded memory management with high allocation/deallocation rates
    • needs to be persuaded to releases memory to the OS:
      it only releases to the system under two occasions: Freeing another part of the memory, or asking it to release all parts marked as freed.

    • has no debugging facilities

The differences make it a challenge to integrate in your development and deployment process: because of the debugging facilities, you’d like FastMM in all your environments, but TCMalloc in multi-threaded environments with high allocation/deallocation rates.

One possibility is to have your CI environment deliver both in all stages, run all tests on both, then choose the final one depending on your run-time configuration.

That gives a burden on configuring your Continuous Integration, but the gain might outweigh this cost.

Relevant links from the Facebook thread:


Posted in Delphi, Development, FastMM, Software Development | Leave a Comment »

Useful settings for FastMM4 to tracking bottlenecks in multi-threaded memory allocation

Posted by jpluimers on 2019/05/23

Interesting thread that reminded me of the relatively new FastMM feature to track down lock contention and cope with it using release stacks:

[WayBack] I try use FastMM4 to tracking bottleneck in allocating memory. I was inspired by this Primož movie: When I… – Jacek Laskowski – Google+

The changes by Primož have added these two new conditional defines to the FastMM4 codebase:

These options are mutually exclusive.

This was the original post it got introduced in [WayBack] The Delphi Geek: Finding Memory Allocation Bottlenecks with FastMM4 and merged into the main repository.

FastMM introduction: [WayBack] The New Memory Manager In BDS 2006 – by Pierre le Riche.

It also taught me about [WayBack] RAMDisk – Software that Accelerates, Protects, Optimizes – Server Memory Products & Services – Dataram.

Primož stores his DCU files there: much faster than SSD, and far less wear on your SSD; see


Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, FastMM, Software Development | Leave a Comment »

Have NoMessageBoxes depend on a global boolean · Issue #58 · pleriche/FastMM4 · GitHub

Posted by jpluimers on 2018/08/16

Reminder to self: [WayBackHave NoMessageBoxes depend on a global boolean · Issue #58 · pleriche/FastMM4 · GitHub


Posted in Delphi, Development, FastMM, Software Development | Leave a Comment »

A success story – kudos to ScaleMM, +André Mussche… – Ondrej Kelle – Google+

Posted by jpluimers on 2018/08/15

Though no maintenance for over 2 years, it ScaleMM seems among the fastest of Delphi memory managers: [WayBack] GitHub – andremussche/scalemm: Fast scaling memory manager for Delphi

Full story via [WayBackA success story – kudos to ScaleMM, +André Mussche… – Ondrej Kelle – Google+ at [WayBack] just tried Scaled MM – cut the time for 100k down from 51 minutes to 40 minutes. That’s with 18 (9+9) cores allocated to the app and 2 to everything else. Wow, allocating 8 + 8 and the time drops even more… – Russell Weetch

Two lessons on multi-threading here:

  • use a memory manager that copes well with threads
  • do not allocate more busy threads than available (hyper-threaded) cores

Some history (as ScaleMM, TopMM and FastMM seem to be related):

  • A bit of history here: at the time we had the mm contest. Not many people had access to 8 cores+, we had…. Andre and Ivo were both colleagues of mine at that point, although working for different companies. We needed (stock trading, Ivo and me) something to scale and Ivo wrote topmm, which still performs better on multi-cores than fastmm and has less assembler code. Andre improved on Ivo’s concepts and yes, it really outperforms fastmm on multi-cores today.
    It also out-performs most C family provided mm’s. Note I was not massively involved, but both Ivo and Andre were. And both did a proper job. So KUDOS to them.
    Note these (fastmm and topmm) were written with multi-core in mind. The practical results at the time were often under-estimated, because few people had access to the real hardware. Most of us running two cores at most. Nice to see that the concept those two programmers pursued still pays dividend in 2018!
  • Read: ScaleMM and TopMM and FastMM… Keyboard left me..
    (I wrote COMMM as a joke..!).
  • [WayBack] TopMemory v3.55. High Performance. Fully Scalable. Free. Memory Manager. for. Delphi – PDF
  • [WayBack] FPC Anagrams

There are also some IntelTBB memory manager references at [WayBack]


Posted in Delphi, Development, FastMM, Software Development | Leave a Comment »

“Unknown function at TMethodImplementationIntercept”

Posted by jpluimers on 2018/06/01

Reminder to self: when you get Unknown function at TMethodImplementationIntercept in a Delphi stack trace from the Exception.StackTrace property or FastMM memory report:

  1. Ensure you generate a .MAP or .TDS file with full debug information
  2. Copy the .MAP or .TDS files to directory of your EXE.


The Exception.StackTrace was introduced in Delphi 2009 that extended these [WayBackException Members:

Some notes:

  • Fields where you can put hooks in; if there is no hook in place, they won’t be used:
    • [WayBackException.GetExceptionStackInfoProc Field GetExceptionStackInfoProc: function (P: PExceptionRecord): Pointer;
      • This function is called to return an opaque data structure that contains stack information for the given exception information record. This function will be called when the exception is about to be raised or if this is an external exception such as an Access Violation, called soon after the object is created.
    • [WayBackException.CleanUpStackInfoProc Field CleanUpStackInfoProc: procedure (Info: Pointer);
      • This function is called when the destructor is called to clean up any data associated with the given opaque data structure.
    • [WayBackException.GetStackInfoStringProc Field GetStackInfoStringProc: function (Info: Pointer): string;
      • This function is called to return a string representation of the opaque data structure returned by GetExceptionStackInfoProc

TMethodImplementationIntercept was introduced in the System.Rtti unit of Delphi XE6 [WayBack]:


Example code:

Posted in Delphi, Development, FastMM, Software Development | Leave a Comment »

%d bloggers like this: