Performance regression during PBF scanning/parsing between 2024-02-10 and 2026-02-07 (high system CPU, ~30% slower)

[pa5cal]

I’m seeing a significant performance regression when running tilemaker on a full planet.osm.pbf, comparing two builds from different points in time. With identical input data, config files, and command-line parameters, the newer version is about ~30% slower overall. The main difference is already visible during the initial PBF scanning/parsing phase.

Versions

• Older version: tilemaker built from source around 2024-02-10
• Newer version: tilemaker built from source around 2026-02-07

Both built on the same machine with the same compiler/toolchain.

Command used

tilemaker
--threads 40
--fast
--no-compress-nodes
--no-compress-ways
--materialize-geometries
--input planet.osm.pbf
--config my-config.json
--process my-process.lua
--output planet.mbtiles

Observed behavior

In the 2024 build, the scanning/parsing phase shows almost no system CPU usage and proceeds relatively quickly. In the 2026 build, the scanning/parsing phase shows ~60% system CPU usage (as observed in top) and takes noticeably longer. Overall runtime is approximately 30% longer in the newer version. The behavior during scanning feels similar to disk-backed processing, even though --store is not enabled.

Does this look like an expected change in the scanning/memory path, or did I miss a new parameter or a change in default behavior?

[systemed]

It's not an expected change and it's not something I've noticed, so it would be good to identify what's going on here. Usually my first port of call for performance slowdowns is polygon geometry, but if you're using the same dataset I don't see anything that would have caused that.

Couple of questions:

• do you know if the two versions were built with the same version of boost::geometry?
• is there anything unusual about your JSON/Lua config worth noting?