Wirklich erstaunlich, die Benchmarks sehen für mimalloc ja in quasi jeder Hinsicht prima aus. Wohlgemerkt stammen diese vom Entwickler mimallocs selbst, sodass weiterhin eine gesunde Skepsis verbleiben sollte.
Hoffentlich wurde hier möglichst objektiv und unvoreingenommen getestet, insbesondere also keine ergebnisorientierte Wahl der Benchmarksoftware (bzw. Ausschluss derer) vorgenommen.
Es wird sich zeigen, ob nicht doch noch gerechtfertigte Anwendungsszenarien/Workloads, die mimalloc in den Schatten stellen, gefunden werden.

Meine kurze Recherche ergab, dass die Doku teils nicht vollständig zu sein scheint, z.B. unter 'Modules -> Runtime Options'.

Abgesehen davon, was hielte bspw. die Entwickler von musl, glibc, FreeBSD, Mozilla oder Chromium davon ab, nun den Allokator zu wechseln? Sind/ist es vielleicht:
a) der bestehende Algorithmus Architekturen unterstützt, die mimalloc nicht unterstützt oder unterstützen wird können,
b) der bestehende Algorithmus implementiert Features, die sich nicht oder nur unter unverhältnismäßigen Umständen für/in mimalloc realisieren/implementieren ließen,
c) der bestehende Algorithmus ist universeller tune- und anwendbar,
d) mimalloc für "wichtige Workloads"® suboptimal oder ungeeignet ist,
e) die teils unvollständige Doku von mimalloc / bessere Doku des bestehenden Algorithmus,
f) Momentum und Entwicklererfahrung für bestehenden Algorithmus,
g) Abhängigkeiten von bestehenden Implementierungsdetails (also Bug für Bug), z.B. für Anwendungen oder Kunden,
h) die Lizenz (MIT sollte doch für fast jeden Einsatzzweck reichen), oder
i) NIH?

Weiß jemand mehr?