libviprs benchmarks

This is the result the PMTiles work was for, and it is an exact one. Both backends were handed the same tiles and asked to store them. PMTiles archive finished with 1 filesystem entry; Directory tree finished with 22127 of them. Every tile is in both, and across all 6 cells the two byte totals never differ by more than 0.016%.

No bands on any of this, and no chart of it either. These numbers do not vary: they came out the same on every repetition, and they came out the same on the capture before this one on a busier host. A trend line and an error bar are both lies about an exact number, so they go in a table with equality verdicts, and when one of them does move between runs that shows up on the version axis further down as a rule carrying the commit that moved it.

The artefact digests differ, and they have to: one is a single archive and the other is a tree of loose files, so the bytes on disk are not the same bytes even when every tile in them is. What has to agree is the tile count, and it does, in every cell. allocated_bytes is the one that moves, because every loose tile rounds up to a filesystem block and a single archive rounds up once.

All three build the same tiles from the same source and produce the same tile count, which the invariants below say exactly. Where they part company is how much of the image they are holding while they do it. At 12000x8400@256+c1, 2119 tiles, the monolithic engine peaks at 652.4 MB resident against streaming's 333.5 MB, a factor of 1.956, for wall times of 2926 ms against 3442 ms, 17.6% apart. The tracked working set underneath it is starker still: 288.4 MB against 27.47 MB.

Wall time (ms, lower is better)

Peak resident set (MB, lower is better)

Tracked working set (MB, lower is better)

Throughput (1/s, higher is better)

What the thread count costs in memory

Every row is the same image built twice, once on 1 thread and once on 6, with the peak resident set of each build beside the other. Read the bottom row: at the small end every engine is dominated by fixed setup, and a percentage there is mostly about the setup. At 12000x8400@256, monolithic and streaming do not move (+0.1%, +0.0%). mapreduce rises with the thread count (+4.7% at that size), and across every size it runs +0.3% to +10.1%. Throughput barely moves either way, which is in the table above: the thread count is buying memory here rather than speed.

• monolithic holds the whole image, so the thread count changes nothing about what is resident.
• streaming works a strip at a time, so its working set is bounded by the strip rather than by the thread count.
• mapreduce keeps several strips in flight, which is what buys the parallelism and what it pays for in resident memory.

One point per archived run, per family, on its own version axis. The band is the replicate spread measured inside that run rather than a model fitted to anything, and a chip only ever appears on a cell that is gateable: the right repetitions, a timer that did not saturate, a confidence its own producer signed off, and a calibration fitted for this host and filesystem.