Re: New Control Centre

[jamie <jamiemcc blueyonder co uk>]

On Tue, 2007-02-06 at 11:07 -0500, JP Rosevear wrote:
> On Tue, 2007-02-06 at 13:43 +0000, jamie wrote:
> > On Tue, 2007-02-06 at 08:29 -0500, JP Rosevear wrote:
> > > On Tue, 2007-02-06 at 10:14 +0000, jamie 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
> > > 
> > > They are already indexed in beagle, so it would be fairly easy to do
> > > this with libbeagle right now, but you'd still have to mimic all the
> > > tree building code with the categorizations in gmenu.
> > 
> > 
> > you would not have to do that with tracker - you could just say get me
> > all apps in category X or app starts with "ev*". 
> 
> How do you display categories without knowing the categories?  You have
> to read the .menu file and you still construct the queries based on the
> that query language.  Are you really not going to cache that in memory?

if the indexer has indexed them right and put them in sqlite then
category list is simply:

select distinct category from applications

do you want me to write this for you? (we can have the sqlite db in a
neutral place and Beagle and/or Tracker can update it while indexing)

> 
> > A sql database is much faster and useful for that than a lucene based
> > indexer like Beagle. 
> > 
> > Sqlite uses btrees so theres no need to maintain trees in memory when
> > you use the right technology. 
> > 
> > (lucene/beagle uses hashtables and is not comparable to an btree based
> > sql database. Hashtables are useless for wildcard searches whereas
> > btrees are fully optimised for this as they store stuff in alphabetic
> > order as opposed to being randomly distributed in a hash)
> 
> Lucene and beagle have wildcard support and it works quite well. 

The only way to do wildcards with a hashtable is a full table scan - if
you have a million unique words/keys in the hashtable then you have to
glob each one to determine if the word matches the wildcard.

The above is ridiculously slow compared to a btree which sorts the words
in alphabetic order so only a small subset needs to be searched.

thats not an attack on lucene/beagle - its just a *big* advantage of
btrees over hashes and thats why you really should use sqlite here. 



> 
> -JP