Caching icon theme information

[Owen Taylor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20041015/cd1e723a/attachment.pgp