> What you describe (compiled files in /etc) are system-global default values. You only need those for multi-user environments.
Well, I work as a systems administrator...
>> I doubt anybody can measure the parsing advantage of a binary format, but the drawbacks are
> The performance advantages are massive.
The advantages over reading a big unsorted chunk of text, maybe measurable in an isolated benchmark - depending on the size of the text. But it's not a good idea to put everything in one place.
With the conventional one-file-per program approach the existing file system (instead of custom binary datastructures) is used to speed up the access.
> The dconf database is just a hashtable which can be directly mmap'ed, so no parsing happens at all.
As an aside, mmap is not necessarily faster, or may even be slower. It's probably not worth bothering except in extreme cases. What matters is caching.
"No parsing happens at all", hardly. A hash table just leads to the information. You still have to interpret it. And I assume dconf can only be queried over dbus? This would mean serialization, deserialization, and lots of context switches.
> This does matter for settings which are read hundreds of times (your current desktop theme, for example).
Not convinced. If most keys were read many times, something was very wrong. No. Most things are read by exactly one program.
The pure act of reading config files is neglibible compared to what other things happen at start-up. A process spawn costs about 1ms. Loading the program code itself is a hell of a lot more expensive than loading a tiny text configuration file. There simply is no performance gain coming from putting everything on one crap pile. But it has serious practical disadvantages.