Unfortunately the benchmarks results haven’t been updated in 6 years. In theory the project code itself does support mimalloc but it’s not in any published results so unclear how it fares. And the tcmalloc variant it compares itself against is the gperftools fork from a dump many many years ago instead of what’s actually used that Google only released again recently (keeping the same tcmalloc name but putting it in a standalone repo)
I tried rpmalloc in my application ~5 years ago. For the particular malloc pattern in my code, rpmalloc was much slower than glibc, musl and jremalloc. Tcmalloc was the fastest IIRC, but it had large overhead on memory. My reflection was that an allocator good in a few benchmarks may not indicate its real-world performance.
Tcmalloc of 5 years ago is very very different from the standalone one released in the past couple of years. Both versions also have a lot of knobs to tune the overhead (the latest one being much better about giving memory back). Still, tcmalloc’s heritage is large servers running in the cloud. Mimalloc may make different trade offs and Google uses Scudo on Android instead of jemalloc (LLVMs hardened allocator sharing some of the ideas of tcmalloc).