[bostik]

For a brief period of time, binary configs[0] were a thing. In mobile world only, but still. It wasn't that people generally wanted them, but because random seek I/O latency on early mobile devices (and especially on their eMMC storage devices) was atrocious.

Opening up tens or hundreds of XML config files for resync was disgustingly slow. I've developed software on Maemo and Scratchbox; the I/O wait for on-device config changes was a real problem. So of course someone came up with a modified concept of Windows registry - a single, binary format config storage, with a suitably "easy" API. As a result you'd sacrifice write/update latency for the cases where you wanted to modify configurations and gain a much improved read/refresh latency when reading them up.

Of course that all broke down when reading a single config block required to read the entire freaking binary dump and the config storage itself was bigger than the block device cache. Turns out that if you give app developers a supposedly easy and low-friction mechanism to store app configs, their respective PMs would go wild and demand that everything is configurable. Multiply by tens, even low hundreds of apps, each registering an idle-loop callback to re-read their configs to guarantee they would always have the correct settings ready. A system intended to improve config load/read times ended up generating an increased demand for already constrained read I/O.

0: https://wiki.gnome.org/Projects/dconf