Re: Performance ideas (resend) ...

[Matthias Clasen <matthias clasen gmail com>]

On Wed, Mar 4, 2009 at 4:39 PM, Michael Meeks <michael meeks novell com> wrote:
> Hi Matthias,
>
> On Wed, 2009-03-04 at 00:56 -0500, Matthias Clasen wrote:
>> The culprit is the GnomeDesktopThumbnail code in
>> libgnomedesktop/gnome-desktop-thumbnail.c
>
>        Oh - nice; and any idea why we fetch each key twice ? ;-) it looks like
> a couple of processes initialise the thumbnailer [ but perhaps this is
> again a SLED-specific joy with the main-menu (?) ].

I see GnomeDesktopThumbnailFactory used in a couple of control-center
capplets, in eog, in cheese (?), gsearchtool,
but mainly in nautilus, which has a background thread for generating
thumbnails that are fed to it via a queue.

Since that is already async wrt to the rest of nautilus (and nautilus
already has support for requeueing thumbnail requests), I thought it
would be worthwhile to see if it is possible to somehow make the
factory read its gconf keys on demand. I've attached the resulting
proof-of-concept patches for gnome-desktop and nautilus.

What these patches do is to give the factory a !preloading mode. In
that mode, can_thumbnail() may return not only true/false, but also
"maybe", in case the gconf keys for the mime type in question haven't
been read yet. I also set up an idle to read the gconf key, in that
case, so that trying again later will hopefully yield a yes or no
answer.
When nautilus gets a "maybe", it simply puts the thumbnail request on
hold for a second, and then retries it.

I haven't checked that the thumbnailing functionality has survived
this operation unharmed, but I did verify that the number of
thumbnailer-related gconf roundtrips is reduced from ~200 to ~10 for
me.


Matthias