xfconf optimisation

[Brian J. Tarricone]

Nick Schermer wrote:
> 2009/5/15 Brian J. Tarricone <brian at tarricone.org>:
>> So... please test, especially on both really slow and really fast hardware.
> 
> Can't compile it:
> sed -i -e 's/^\([[:space:]]\+GValue[[:space:]]\+[^=]\)\+;\1 = { 0,
> };/' xfconf-dbus-bindings.h
> sed: -e expression #1, char 59: unterminated `s' command
> make[2]: *** [xfconf-dbus-bindings.h] Error 1

Yeah, I suck.  Testing one thing on the command line and then checking 
in something else is a bad idea.  It should work now, though.

>>  If anything looks weird, I'll revert.  If it looks ok, I'll commit it to
>> the 4.6 branch (it's only on trunk now).
> 
> I don't think it's a smart idea to backport this because of the
> possible unintended consequences. "Bugs fixes only", like wise man
> once told me ;-).

Yeah, I'm not so sure about it either.  Personally I do consider 
performance issues as bugs, though.  Every Xfce app hitting dbus 30+ 
times on startup and having to wait for *each* request to complete 
before proceeding is pretty awful.

This thing seemed to be a least intrusive fix.  I'm planning on 
libxfconf client-side caching for 4.8, and possibly threading in xfconfd 
(this will be hard to get right, so maybe not threading, but just async 
request handling).  But both of those things are *definitely* too big 
for the stable branch.

Of course, Robby has already noticed a potential issue with xfdesktop 
rearranging his icons on startup, possibly because of a delay in the 
settings fetching, so it may be a moot point and I might back out the 
change entirely.

But still, there are big performance problems with how xfconf works 
right now, and I'm not entirely sure how to best work them out.  dconf 
will be using a hybrid dbus daemon / daemonless system so apps can start 
up quickly by using a client library that reads from the config store 
directly without using dbus.  That sounds like it might be a bit complex 
for what we want (or we might just make yet another config system change 
in 4.8; sigh).  But the fact still remains that blocking IPC is a bad 
idea.  But getting settings via callbacks doesn't sound particularly 
pleasant from a development point of view either.

I dunno... need a lot more thought about this.

	-b