Caching icon theme information
mclasen at redhat.com
Tue Oct 19 21:04:08 EEST 2004
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  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.
I made an attempt to quantify the startup time win by measuring the
time it takes to start up gedit until it maps the first window on a
system with a cold cache.
with cache: 0.360289 seconds
without cache: 1.612272 seconds
I don't claim that these numbers are entirely accurate, but the
difference is large enough to justify the claim that caching does
improve startup time considerably, independent from overall memory
savings due to sharing the cache.
More information about the xdg