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 2,953 other followers

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:


5 Responses to “Delphi memory allocators and configuration notes in multi-threaded environments with high allocation/deallocation rates”

  1. Roberto Della Pasqua said

    Will update it soon with a pair of bugs correction

  2. Intel libraries are better than google performance, more reliable and fast, take a look

  3. I did a lot of research on a dozen of mem allocators, and found the Intel TBB (free license) to be the most fast, reliable and less prone to fragmentation for multithreaded apps.
    Feel free to check with pascal wrappers over the libraries.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: