Linked by Antonio Ospite on Fri 21st Oct 2011 23:35 UTC
Gnome Antonio Ospite explores Gnome 3 in fall-back mode and tries to make it look and behave more like Gnome 2.32 again. This summer Linus Torvalds made it to the news for complaining about the gnome-shell design; Gnome fall-back mode is the solution for those like Linus who can't - or better, do not want to - use gnome-shell just yet.
Thread beginning with comment 493916
To view parent comment, click here.
To read all comments associated with this story, please click here.
Soulbender
Member since:
2005-08-18

as far as I know the settings are mmap'd shared and then all processes can read from it at start-up, that's not possible with a text-file.


What makes you think it's not possible to mmap text files? it works just as well with "binary" as "text" files.

Reply Parent Score: 3

saynte Member since:
2007-12-10

Because you still have to lex and parse the text file, which is a lot more complicated than the system needed to examine GVariant data. The dconf system was basically built to be very fast, faster than text, and I really can't see the disadvantages in designing it for speed.

If you don't like their decision to use dconf: that's fine. But please, don't insinuate that they are somehow amateurs for not using text-files. The dconf system wasn't a premature optimization, it was in response to a performance problem.

Reply Parent Score: 2

Soulbender Member since:
2005-08-18

Because you still have to lex and parse the text file, which is a lot more complicated than the system needed to examine GVariant data.


This has nothing to do with mmap'ing files and everything to do with parsing data.

The dconf system was basically built to be very fast, faster than text,


I'm sure it's faster (by whatever few milliseconds), that's not the point.
Just because gconf can't effectively handle text files it doesn't mean that text files are ineffective. XML isn't the most efficient and quickly parsed format.

The dconf system wasn't a premature optimization, it was in response to a performance problem.


Why aren't they writing GNOME assembler then? That would really speed things up. Or at least statically link everything because all that dynamic library loading and symbol resolving is even slower than reading and parsing configuration files.
Maybe we should stop using languages like Python, Ruby and Perl because they're "slow". Is GNOME going to be C/C++ only since for Python and other interpreted languages reading config files is far from the most time-consuming task when it comes to startup.

Edited 2011-10-24 05:20 UTC

Reply Parent Score: 4

phoenix Member since:
2005-07-11

So you parse the file once on load, stuff the settings into shared memory, and carry on. The end result is basically the same: some region of memory with all the settings stored there, shared amongst the system.

If the parser is slow ... you optimise the parser. Why rip it out and replace it wholesale with a binary option? Hasn't the horror that is the Windows Registry been enough of a red flag for everyone to avoid recreating it?

Reply Parent Score: 2