xfdesktop menu cache

[Olivier]

Brian,

Actually, I've just send it: Overall startup (after rebooting, so the OS
cache doesn't come in the way) time has decreased from 35 secs to 20
secs!

Cheers,
Olivier.

On Fri, 2004-07-16 at 23:08, Brian J. Tarricone wrote:
> cool, i'd be very interested in seeing some real numbers.  on the 
> downside, the cache generation causes a bit of a performance penalty, so 
> the initial menu generation will take longer than it used to.  not 
> really sure that there's a way around this, though.
> 
> 	-brian
> 
> 
> On Fri, 16 Jul 2004, Olivier wrote:
> 
> > Hi Brian,
> > 
> > That's great news, I'll try to come up with some benchmarks to see what
> > it buys us!
> > 
> > Cheers,
> > Olivier.
> > 
> > On Fri, 2004-07-16 at 21:21, Brian J. Tarricone wrote:
> > > hi all-
> > > 
> > > i just committed a caching system for the xfdesktop menu.  basically, as 
> > > it's creating the menu, the cache creates a tree structure (using 
> > > GNodes) to describe the menu.  after the menu's done, the tree gets 
> > > written to an XML file, in the same format as ~/.xfce4/menu.xml.  in 
> > > another file, i store a list of all the relevant menu files and .desktop 
> > > directories along with their mtimes, to check for cache validity.  on 
> > > startup, xfdesktop reads this file, checks the mtimes, and matches them 
> > > against the values in the file.  if there are filesystem changes, we 
> > > redo the menu, if not, we simply parse the cached XML file instead of 
> > > ~/.xfce4/menu.xml.
> > > 
> > > just to confuse the issue (^_~), the cache files are stored in 
> > > ~/.cache/xfdesktop.  i'll change it when we decide on what to do about 
> > > the config dir structure.
> > > 
> > > this could use a lot of testing, though it appears to work ok for me.  
> > > happy bug-hunting!
> > > 
> > > on a side note, i've been urged to do the menu generation in a separate 
> > > thread.  i don't think this will buy us anything, because the menu 
> > > generation is very gtk-heavy, so i'd have to wrap the _entire_ thing in 
> > > a big gdk_threads_enter()/gdk_threads_leave() pair, and any other 
> > > gtk-related stuff in the main thread would get blocked anyway.  as it 
> > > stands, the initial menu generation (when xfdesktop starts) is idled via 
> > > g_idle_add(), and xfdesktop connects to the session manager before this 
> > > runs, so it's about as fast as it can be, IMO.  if anyone has any better 
> > > ideas (aside from rewriting it to be faster - hah), please let me hear 
> > > them.
> > > 
> > > 	-brian
> > > 
> > > _______________________________________________
> > > Xfce4-dev mailing list
> > > Xfce4-dev at xfce.org
> > > http://lunar-linux.org/mailman/listinfo/xfce4-dev
> > 
> 
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://lunar-linux.org/mailman/listinfo/xfce4-dev
-- 
 - Olivier Fourdan - fourdan at xfce.org - http://www.xfce.org -