The Wiert Corner – irregular stream of stuff

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

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

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

    Join 4,262 other subscribers
«
»

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 [Archive.is/WayBack] 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:

–jeroen

This entry was posted on 2020/02/20 at 18:00 and is filed under Delphi, Development, FastMM, Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

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

  1. Roberto Della Pasqua said

    2020/03/04 at 10:06

    Will update it soon with a pair of bugs correction

    Reply

  2. Roberto Della Pasqua said

    2020/02/21 at 16:42

    https://github.com/RDP1974 Intel libraries are better than google performance, more reliable and fast, take a look

    Reply

  3. Roberto Della Pasqua said

    2020/02/21 at 09:13

    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 https://github.com/RDP1974/Sea-Delphi-RTL-IIS-Filter with pascal wrappers over the libraries.

    Reply

Leave a comment

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

«
»