mORMot Open Source

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 15,583

Website

The Point about current mormot.core.fpcx64m.pas unit

Thanks to Landrix feedback and pull requests, our MM unit for x86_64 and FPC did have some new default settings, and new algorithms.
Some reference about the context: https://github.com/synopse/mORMot2/pull … 5398319192

I made some tests with our TFB sample project, to have some ideas.
The server was always run as:

$ ./raw -s 1 -t 10

AI-generated content begins here

Updated comparison on current mORMot 2 master. All runs on the same machine with identical parameters.

Test setup

• Linux x86_64

• ulimit -n 100000

• wrk parameters: 512 connections, 10 threads, 5-second runs

• Endpoints from the official techempower-bench

• The database here is SQlite3 because we wanted to be CPU and memory constrained for the tests

• /fortunes = ORM data context + TSynMustache.RenderDataArray (higher allocation pressure, and a giant lock around the ORM layer)

• /rawfortunes = direct DB output + per-connection TSynMustacheContextData (much lighter)

Typical commands used:

ulimit -n 100000

wrk -c 512 -t 10 -d 5 http://localhost:8080/plaintext
wrk -c 512 -t 10 -d 5 http://localhost:8080/json
wrk -c 512 -t 10 -d 5 http://localhost:8080/fortunes
wrk -c 512 -t 10 -d 5 http://localhost:8080/rawfortunes

Requests/sec summary

Endpoint         SERVER          BOOSTER         libc (fpclibcmm)
--------------------------------------------------------------------
/plaintext      ~1.23 M         1.234 M         1.277 M
/json           ~1.16 M         1.191 M         1.217 M
/rawfortunes    ~1.07 M         1.086 M         1.107 M
/fortunes      103-105 k        117.2 k         117.2 k

(The two independent SERVER passes were very close, so the values above are representative.)

Memory footprint (idle after the runs)

                RES          VIRT
------------------------------------
SERVER         ~14 MB        ~24 MB
BOOSTER        ~15 MB        ~82 MB
libc           ~14 MB       ~730 MB

Physical RAM usage is essentially identical. The big difference is virtual address space: glibc pre-reserves large arenas, while fpcx64mm stays much more conservative.

fpcx64mm internal statistics

SERVER mode:

Flags: SERVER  assumt tinpt erms debug repmemleak
Small:  1K/160KB  including tiny≤128B arenas=8 fed from Medium
Medium: 7MB/7MB    peak=7MB  sleep=1
Large:  0B/320KB   sleep=0
Total Sleep: count=1
Small Blocks since beginning: 63M / 6GB
Dominant sizes: 64, 112, 48, 80, 128 B

BOOSTER mode:

Flags: BOOSTER  assumt smallpools tinpt medpt erms repmemleak
Small:  1K/160KB  including tiny≤256B arenas=128 pools=31
Medium: 45MB/45MB  sleep=3
Large:  0B/0B     sleep=0
Total Sleep: count=3
Small Blocks since beginning: 67M / 6GB

Both modes show almost zero contention (Total Sleep 1–3). BOOSTER uses more medium memory (45 MB vs 7 MB) as expected from the extra arenas and per-thread medium pools, but live small-block footprint stays tiny in both cases.

Analysis

• On the lightly allocating endpoints (/plaintext, /json, /rawfortunes) all three allocators are excellent. libc holds a small 3–5 % advantage.

• On the more realistic /fortunes path (ORM + Mustache) the picture changes:
    - SERVER trails by roughly 12–14 %
    - BOOSTER fully closes the gap and matches libc

• The BOOSTER design (128 tiny arenas ≤256 B, multiple small pools, medium-per-thread) is clearly effective on this workload and concurrency level.

• Contention remains negligible even under BOOSTER, which is a good sign for the current locking/spinning implementation.

• Virtual memory behaviour of fpcx64mm is still far more frugal than glibc. This is usually irrelevant on 64-bit servers but can matter in constrained environments.

Take-away on this hardware

FPCMM_SERVER is already very strong for typical service loads. 
FPCMM_BOOSTER brings the allocation-heavier ORM+template path up to libc level while keeping a much smaller virtual footprint and near-zero sleep counts.

Next interesting measurements would be longer sustained runs (to observe arena growth/fragmentation) and a direct comparison with mimalloc via LD_PRELOAD on the same binary.