Re: [Nautilus-list] Nautilus Performance Analysis

Alan Cox <alan lxorguk ukuu org uk> writes:

> > We are reading it with gdk-pixbuf. I imagine this is a bug in the 
> > gdk-pixbuf loader architecture. Perhaps the thing to do is to find a way 
> > to add a level of caching. The fix to this is probably to change eel's
> Or to fix gdk_pixbuf. What else uses gdk_pixbuf to load large jpg images
> and I'll do some comparison tests

You can try eog or gqview.  However, I think the problem is not with
gdk_pixbuf.  The jpeg loader either just passes a FILE * to libjpeg, or
parses it from data fed in progressively.  The image loader seems to
read the file in 4K chunks.  I bet upping this block size would help
performance a lot -- though I'm not sure what it should be upped to.
Anyone have any ideas?

> Looking at the I/O patterns it seems that the code tackling the mini jpeg
> and text file stuff is running in parallel to the original directory scan.
> That seems odd to me in terms of performance but I have no measurements to
> back up the instinct

I think that is all done asynchornously, so it can put up temporary
icons, and then load the real mini-icons in an idle loop.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]