The Wiert Corner – irregular stream of stuff

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

  • My badges

  • Twitter Updates

    • RT @bslagter: 19/ Mijn suggestie is om massaal asymmetrische maatregelen te omarmen, bedenken, ontwikkelen. Modieuze mondbedekking, slimme… 37 minutes ago
    • @dzjr74 Langs stompetoren. Jeugdsentimenten. 41 minutes ago
    • @Tijgernest @dzjr74 Hier al BBQ geur. Tenminste: iemand in de buurt probeert zo'n ding aan te krijgen. Meer stank dan warmte (: 42 minutes ago
    • RT @wimdaniels: Het wekelijkse zondagse taalspel gaat vandaag op herhaling met ‘afkappertjes’. Laat van een woord of woordgroep de laatste… 56 minutes ago
    • Ergens in de buurt probeert iemand een BBQ aan te steken. Meer stank dan warmte (: 57 minutes ago
  • 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,880 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 )

Google photo

You are commenting using your Google 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: