From 2ed6c3d1afbe33459cde8855299d3c327ffa30dc Mon Sep 17 00:00:00 2001 From: Robin Haberkorn Date: Sun, 20 Jul 2025 13:57:16 +0300 Subject: FreeBSD: enable dlmalloc by default (--enable-malloc-replacement) * After re-benchmarking the performance, I in fact detected a 20-25% speedup if memory limiting is active. Both using `time` and the builtin monotic timer ::^B. When memory limiting is disabled, there is no detectable difference to jemalloc. The following test case was used: sciteco -e '::^BUs 100000<@^U[^E\a]"^E\a" %a> ::^B-Qs=' * I also played around with getrusage(), but it doesn't seem to be a viable API for detecting the currently used RSS, i.e. it does not allow recovering from OOMs. --- src/memory.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) (limited to 'src') diff --git a/src/memory.c b/src/memory.c index ea056bc..90a5dd8 100644 --- a/src/memory.c +++ b/src/memory.c @@ -251,13 +251,19 @@ * It is of course possible to query the program's RSS via OS APIs. * This has long been avoided because it is naturally platform-dependant and * some of the APIs have proven to be too slow for frequent polling. + * Also, this will only reliably work if malloc_trim(0) does what it's + * supposed to do. * * - Windows has GetProcessMemoryInfo() which is quite slow. * When polled on a separate thread, the slow down is very acceptable. + * - POSIX has getrusage(). + * __Its performance on different OS is still untested!__ + * It reports in different units on different systems, see + * mimalloc/src/prim/unix/prim.c. + * The maxrss field does not shrink even with a working malloc_trim(). * - OS X has task_info(). * __Its performance is still untested!__ * - FreeBSD has sysctl(). - * __Its performance is still untested!__ * - Linux has no APIs but /proc/self/statm. * Reading it is naturally very slow, but at least of constant time. * When polled on a separate thread, the slow down is very acceptable. @@ -471,10 +477,8 @@ teco_memory_get_usage(void) /* * Practically only for FreeBSD. * - * The malloc replacement via dlmalloc also works on FreeBSD, - * but this implementation has been benchmarked to be up to 4 times faster - * (but only if we poll in a separate thread). - * On the downside, this will of course be less precise. + * Since FreeBSD supports dlmalloc(), which is generally faster than + * jemalloc with a poll thread, this is not usually required. */ static gsize teco_memory_get_usage(void) -- cgit v1.2.3