Caching icon theme information

[Matthias Clasen]

On Fri, 2004-10-15 at 12:32, Owen Taylor wrote:
> On Fri, 2004-10-15 at 14:07 +0200, Lubos Lunak wrote:
> > On Wednesday 13 of October 2004 22:17, Matthias Clasen wrote:
> > > Back in May, Owen Taylor proposed [1] caching scheme for icon theme
> > > information, to reduce the amount of stating and disk seeking at
> > > application startup, and to reduce the memory overhead if each app
> > > allocates all the icon theme data separately.
> > 
> >  Since you have an implementation, do you have any numbers? I couldn't find 
> > anything in the links other than the half a megabyte for the BlueCurve theme 
> > in Owen's mail, which looks to me more like a broken implementation. 
> 
> I wouldn't claim that the GTK+ implementation is an *optimal*
> implementation in terms of memory usage, but I certainly checked to make
> sure that it wasn't doing anything ridiculously stupid.
> 
> What sort of number are you looking for? We can't give you numbers for
> KDE with and without an icon theme cache... and to get the GNOME number,
> you really can take 500k and multiply it by the number of processes.
> 
> Perhaps an interesting number is the size of the icon cache files for
> Bluecurve and Hicolor icon themes since that is a pretty tightly
> compressed representation of the data. (There's a 4 byte per icon
> overhead for the unused icon data offset, but that's only 4k / 
> thousand icons.)
> 
> I don't have that data offhand, but Matthias can probably provide it.
> 
> (There also was quite a time overhead for building up the internal 
> data structures and doing readdir on dozens of directories. To some
> extent, the desktops have to cut down strace output just to get the
> kernel people to take them seriously...)
> 
> > You cache only icon locations, and I'd expect the directories contents to be 
> > cached after a first application runs, so I'm just wondering if this all 
> > would be worth it.
> 
> Well, say that GTK+ was using twice as much memory as it needed to use,
> and Bluecurve had twice as many icons as it needed to have. Then you'd
> still be talking about more than 100k of information that could be
> shared. This is comparable to the fontconfig overhead, and I'd consider
> it pretty significant.
> 
> Regards,
> 						Owen

for i in /usr/share/icons/{Bluecurve,hicolor}; do ls -s
$i/icon-theme.cache; du -sk $i; find $i -type d | wc -l; find $i -type f
| wc -l;
done                                                                                
100 /usr/share/icons/Bluecurve/icon-theme.cache
9744    /usr/share/icons/Bluecurve
47
2011
64 /usr/share/icons/hicolor/icon-theme.cache
8752    /usr/share/icons/hicolor
119
1951

So the icon cache for Bluecurve stores the information about 47
directories and 2011 files in ~100k, the cache for hicolor stores the
information about 119 directories and 1951 files in ~64k 


Matthias