Re: New Control Centre

["BJörn Lindqvist" <bjourne gmail com>]

On 2/6/07, jamie <jamiemcc blueyonder co uk> wrote:
> On Mon, 2007-02-05 at 21:19 -0600, Federico Mena Quintero wrote:
> > El mar, 06-02-2007 a las 12:52 +1100, Russell Shaw escribió:
> >
> > > If profiling has to be done to make a menu faster, it is pretty obvious
> > > the system it is built on is stupidly inefficient and broken, especially
> > > if said menu is slow on a 10 year old pc.
> >
> > Ah, bingo.
> >
> > Almost 10 years ago, when GNOME started, we had like three apps we
> > wanted to put in the menus.  So, reading .desktop files from disk didn't
> > seem like a bad idea.
> >
> > Now that we have hundreds of .desktop files, it is not a good idea
> > anymore to have them scattered all around the disk.  You are absolutely
> > right; the system it is built on is stupidly inefficient and broken!
>
> Yes and its fairly easily fixed with tracker once I add .desktop file
> indexing to it
>
> tracker's db is a single file so if it caches all the desktop files so
> it does not have the disk seek penalty ergo all relevant desktop files
> could be pulled from it very quickly. Even better is the fact that
> individual categories can be queried straight from the db so no need to
> hold everything in memory
>
> secondly on systems with spare memory, its db will be in the disk cache
> and therefore will be as fast as holding it in memory but without the
> need to waste any (thats why using a db like sqlite is so much smarter -
> sql is massively more productive to work with and performs tons faster
> than parsing text files)

I do not understand at all. If Control Center has 40 .desktop files,
you need to do 80 disk reads. First you read the 40 .desktop files and
then the 40 icons those files are referring to. How does tracker
reduce the number of disk reads you need to do? I thought tracker was
an indexer and a meta data storage.

--
mvh Björn