3 ms·

Memory allocation behaviour has visible impact also for users of managed languages, and the behaviour of software for end users. In our Python program, a bit o

by nh2 15d ago

Memory allocation behaviour has visible impact also for users of managed languages, and the behaviour of software for end users. In our Python program, a bit of numpy processing of large pictures led to 100 GB not being returned to the OS by glibc's default allocator and the machine running out of memory shortly after. With jemalloc's reliable memory return settings, those problems disappear.

majora2007 15d ago
I'm in the same boat, I just switched to using it for Kavita, which only does some basic open Image -> Thumbnail to smaller size -> write to disk when importing new comics/books and on linux, memory could swell to 10GB and never get released. Switched to jemalloc and instantly memory stayed well below 1GB.
- nh2 15d ago
  Generally yes, but the wording of "instantly" begs for the following pedantic remark: This is controlled by jemalloc settings `dirty_decay_ms`, `muzzy_decay_ms`, and their interaction with `background_thread`. `dirty_decay_ms` currently defaults to 10 seconds, so it's not that instant. That is important e.g. for single-threaded programs that start other programs, such as my Python example: If it starts a subprocess before the 10 seconds elapse after `free()`, Python (and jemalloc) do not run, and get no chance to return memory to the OS. In such cases, either enable `background_thread`, or set the `_decay_` values to `0` to ensure immediate return to the OS upon `free()`. (This costs some performance.) See e.g. https://github.com/jemalloc/jemalloc/issues/2688 https://github.com/jemalloc/jemalloc/issues/2688
stackghost 15d ago
Okay but do you think the hordes of JavaScript developers at FANG can just change the browser’s allocator? The number of programmers who are in positions to care about jemalloc vs other malloc is minuscule

3 ms·

Memory allocation behaviour has visible impact also for users of managed languages, and the behaviour of software for end users. In our Python program, a bit o

by nh2 15d ago

majora2007 15d ago
I'm in the same boat, I just switched to using it for Kavita, which only does some basic open Image -> Thumbnail to smaller size -> write to disk when importing new comics/books and on linux, memory could swell to 10GB and never get released. Switched to jemalloc and instantly memory stayed well below 1GB.
- nh2 15d ago
  Generally yes, but the wording of "instantly" begs for the following pedantic remark: This is controlled by jemalloc settings `dirty_decay_ms`, `muzzy_decay_ms`, and their interaction with `background_thread`. `dirty_decay_ms` currently defaults to 10 seconds, so it's not that instant. That is important e.g. for single-threaded programs that start other programs, such as my Python example: If it starts a subprocess before the 10 seconds elapse after `free()`, Python (and jemalloc) do not run, and get no chance to return memory to the OS. In such cases, either enable `background_thread`, or set the `_decay_` values to `0` to ensure immediate return to the OS upon `free()`. (This costs some performance.) See e.g. https://github.com/jemalloc/jemalloc/issues/2688 https://github.com/jemalloc/jemalloc/issues/2688
stackghost 15d ago
Okay but do you think the hordes of JavaScript developers at FANG can just change the browser’s allocator? The number of programmers who are in positions to care about jemalloc vs other malloc is minuscule