36% from a version number
Counting bytes rather than operations showed our FUSE server moving 295 MB in 56,634 writes. The transport could carry twelve times more per round trip; it was just never asked to.
We had spent two commits looking for the source of our FUSE overhead in the wrong place. Adding byte counters alongside the operation counters settled it immediately: one incremental build moved 295 MB in 56,634 writes — about 5.2 KB per call, against a transport that can carry far more per round trip.
The operation count was not high because the build writes a lot. It was high because every write was small.
fuser gates its FUSE protocol version behind cargo features and defaults to
abi-7-9. Raising it to 7.23 opts into no new capabilities and changes
nothing else, but the negotiated maximum write goes from ~5 KB to ~65 KB:
| time | writes | bytes | |
|---|---|---|---|
default (abi-7-9) | 2.837 / 2.811 s | 56,694 / 56,591 | 294.8 MB |
abi-7-23 | 1.792 / 1.804 s | 4,527 / 4,499 | 295.0 MB |
Identical bytes, 12.5× fewer operations, 36% faster. End to end on the real workload the inner-loop overhead falls from +1.81 s to +1.10 s — 39% of it removed by a one-line dependency change.
We measured abi-7-31 too: 4,047 writes, no further change in time. Taking
the lowest version that delivers the win means fewer protocol differences to
reason about and a lower kernel floor — 7.23 is Linux 4.5.
The part worth keeping: we had been counting operations for two commits and the answer was in the bytes. An operation count tells you how often you crossed the boundary. It cannot tell you whether crossing it that often was necessary.
This also reinstated a claim we had previously retracted — the retraction was the mistake, and it is written up with the others.