Re: [Nautilus-list] Icon factory caching



On Fri, 5 Oct 2001, Darin Adler wrote:

> on 10/5/01 1:01 PM, Alex Larsson at alexl redhat com wrote:
> 
> > The icon factory currently only caches unused icons for 10 seconds. I
> > think this is about the right time since we want to conserve memory, but
> > the problem is that each time you drop the icon from the cache, re-reading
> > it needs to stat a whole lot of files looking for the actual icon file.
> 
> Where does that 10-second value come from?

nautilus-icon-factory.c:

/* This is the number of milliseconds we wait before sweeping out
 * items from the cache.
 */
#define ICON_CACHE_SWEEP_TIMEOUT        (10 * 1000)

> > What i think we need to do is to have a cache inside the icon cache that
> > caches the filenames of the icons. So that we don't have to look around
> > for the icons so much. This is a lot smaller than keeping the actual
> > icons around, so it shouldn't matter that much. We can even cache negative
> > hits (most icon-names have no specific icon for them) as NULL, thereby
> > using very little memory.
> 
> I agree completely. That's exactly what I was planning to do after Alan
> Cox's analysis originally pointed to this problem. I never got around to it,
> but we should figure this one out.
> 
> The trick is to figure out what the key for this new cache is. There are a
> lot of parameters to the "look for icon file" process, so it's not
> immediately obvious what would be in that key.
> 
> My only worry is that we would ideally want the cache to be invalidated if
> someone added icons, and it would be nice to allow adding icons without
> restarting Nautilus. But that's a minor point compared to this area that
> needs major optimization.

On second thought, i think the right way is to readdir the actual pixmap 
directories on startup and theme switch and just keep the existing 
filenames in memory. Then we can avoid stat:ing but still keep the 
existing algorithms.

I guess we could re-read it periodically too, or allow the user trigger a 
re-read.

/ Alex





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