diff options
| author | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2025-07-20 13:57:16 +0300 |
|---|---|---|
| committer | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2025-07-20 14:06:57 +0300 |
| commit | 2ed6c3d1afbe33459cde8855299d3c327ffa30dc (patch) | |
| tree | 8902c7511b485e0b4132b436239a5f03788f50ba /src | |
| parent | 20aef26f311cc04550cc188e237c9288d5fb7b72 (diff) | |
| download | sciteco-2ed6c3d1afbe33459cde8855299d3c327ffa30dc.tar.gz | |
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.
Diffstat (limited to 'src')
| -rw-r--r-- | src/memory.c | 14 |
1 files changed, 9 insertions, 5 deletions
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) |