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 493960
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Apple Plist, Lazy Loading
by saynte on Mon 24th Oct 2011 04:20 UTC in reply to "RE[5]: Apple Plist, Lazy Loading"
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

saynte Member since:
2007-12-10

You'd never mmap and share a file you had to then repeatedly parse, since deserialization of GVariant data is basically trivial, the clients can do it at will. This is mostly besides the point, though.

The switch to binary was *part of* a switch to a faster system, and the entire switch saved them seconds on the start-up time.

It's not premature optimization when they analyze their start-up, see that config loading is taking too long, then address that. That's PRECISELY how you should optimize. You may not agree with their solution, but it works, and it addresses the problem.

There's no real reason to hate on binary files (or text files), each have their advantages and disadvantages.

Reply Parent Score: 2

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

saynte Member since:
2007-12-10

The switch to binary was part of a move to another system. They were changing every part of the system anyway, and I don't think binary files really scared any of them. I mean, so many of the files that we use are binary, why are configuration files the only taboo?

Maybe it's just been a while, but in many years I haven't heard of anything bad related to the binary nature of the windows registry. Could you remind me?

Reply Parent Score: 1