Re: Performance ideas (resend) ...
- From: Matthias Clasen <matthias clasen gmail com>
- To: michael meeks novell com
- Cc: performance-list <performance-list gnome org>
- Subject: Re: Performance ideas (resend) ...
- Date: Thu, 5 Mar 2009 02:02:34 -0500
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
> 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
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
] [Thread Prev