[dktue]

Gain: none in code; it documents a way to make large builds 10–17% faster on Linux without rebuilding: preloading the jemalloc allocator. No new dependency.

While profiling the tile phase on the planet, about a fifth of its CPU time went into the memory allocator (malloc, free and their internals). Preloading a different allocator with LD_PRELOAD showed how much of that is recoverable, without changing any code:

planet in memory, .pmtiles	glibc malloc (default)	jemalloc	change
master + #986, 96 threads (default)	24:43 / 23:50	20:32	−14% to −17%, peak RSS 162.8 → 155.9 GB
all open performance PRs, 96 threads	14:12 / 14:08	12:38	−11%
all open performance PRs, 32 threads	19:11	17:16	−10%
all open performance PRs, Germany, 32 threads	37.5 / 37.4 / 37.5 s	36.2 / 36.0 / 36.0 s	−4%, peak RSS −4%

48-core / 96-thread server, OpenMapTiles profile, Debian/Ubuntu libjemalloc2. jemalloc was faster in every case and never needed more memory. For comparison, tcmalloc (gperftools 2.15) was 25% slower on the planet at 96 threads.

This PR only adds a short paragraph to the "Performance and memory tuning" section of docs/RUNNING.md. If you'd like tilemaker to use jemalloc without preloading, an optional CMake switch to link it would be a possible follow-up, but that adds a dependency, so I've left it out.

🤖 Generated with Claude Code