xfdesktop menu cache

[Brian J. Tarricone]

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
>