xfdesktop menu cache

[Brian J. Tarricone]

On Fri, 16 Jul 2004, Olivier wrote:

> Before upgrading 35 seconds, after 20 seconds. That's definitely a great
> improvement IMHO. 

are you talking total desktop startup time, or just xfdesktop?

> Plus, it seems to me the menu is not blocking anymore (thanks to
> g_idle?) so now, I agree, the thread is not necessary; you are right.

the g_idle thing has been in there for over a month, so i doubt it.
the bulk of the menu creation time is probably in the categorising code, 
as it has to first build a categories tree, and then each .desktop entry 
has to fetch data from it.  as you mentioned earlier, the disk I/O isn't 
helping either.  basically what i'm saying is the actual menu creation 
- as in, the actual creating of the widgets - is a snap.  with the cache 
in place, on my machine (1.8ghz), the menu builds from the cache in a 
small enough fraction of a second that i can't tell.  without the cache, 
it can take up to 5 seconds.  if you go and delete your cache file, i'm 
sure your performance will degrade to as it was before.

i'll dig into the menuspec stuff later to see if i can't make it run any 
faster, but i'm pessimistic.  if all else fails i'll ditch g_idle and 
use g_timeout_add, but that's pretty hacky...

	-brian

> On Fri, 2004-07-16 at 22:04, Olivier wrote:
> > On Fri, 2004-07-16 at 21:21, Brian J. Tarricone wrote:
> > > 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.
> > 
> > I disagree with this point of view. The goal is not necessarily to make
> > it faster, but to allow the user to use its environment earlier.
> > 
> > Lemme try to explain: I have the menu in the panel and the desktop. When
> > booting for the first time, the system "feels" frozen for maybe 1 minute
> > before I can actually run anything. At first, I don't necessarily need
> > to use the menu, so I wouldn't care if it was loading while I'm able to
> > start my mail, terminal, browser, and so on, from the regular panel
> > launchers.
> > 
> > See, I don't want to make it faster (I guess your cache system will do
> > the job btw, we don't need anything more), I want it to be non blocking
> > (that's where a separate thread will help).
> > 
> > Cheers,
> > Olivier.
>