How and what does (plasma theme) caching operate? / KSharedDataCache issue?
christoph at maxiom.de
Mon Sep 17 00:19:28 BST 2012
On Sunday 16 September 2012 19:16:27 Thomas Lübking wrote:
> Because any access to the plasma theme cache takes considerable
> time here, i just took a short look.
> 1. all plasma theme caches are 82324 kB and mostly consist of
> paddings (actually the default one seems to consist of nothing
> else) 2. xz compressing them turns them to ~56 kB
> 3. uncompressing turns them to ~7MB
> 4. accessing them re-turns them to 82324 kB
> - why are there those giant files which mostly consist of paddings
> and take considerable time to load from disk? (the icon cache is
> "only" 11MB) -> Are the paddings mandatory or would it be possible
> to contract the content and omit the paddings?
Cache files are mmap'ed. On systems, where it is supported, the space
needed for the files is pre-allocated from the file system. This has
been done to avoid crashes in disk-full situations. For more
information, see bug 245173. Since I rather want crashes when my root
disk should ever get full, I reverted it locally ;)
> -> Should the cache be split up into "required by everybody"
> (frames etc) and "likely required by the desktop only" (clock,
> calendar, whatnot else)
I don't understand this question. There is one cache for each plasma
theme, and only those pixmaps that have ever been requested actually
land in the cache.
> - (assuming they operate as SHM backends) why does every first
> access from within any process take about the very same time and
> (actually seems to) reload them into FS cache?
> - in case they are and if the files have a fixed layout, why are
> they (apparently) read completely instead of mmapping the relevant
> sections directly? (FS/tuning issue?)
How did you measure, that they are completely loaded? From how I
understand the KSharedDataCache design, it should never do this.
> - is it "legally" possible to keep them compressed on disk and
> uncompress them into and use them from a (compressing) tempfs 
> whenever required  or should i just do such locally (w/o any
> profit for anyone else) - yes i'm aware that i should likely
> (maybe?) recompress them to HDD when exiting the session
There is a review request to add compression to KImageCache.
> - if not, should there be such behavior?
> Sorry if i'm stupid and miss sth. or this is some local issue and
> the cache is mmapped and shared in RAM w/o any overhead for
> everybody else. Cheers,
> PS: yes, it's less a problem with an SDD, but that is no argument -
> those caches do not really act like shared memory at all (at least
> not here)
>  or a memory keeping daemon
>  what is much, MUCH, ***MUCH*** faster when done "by hand" and
> makes using plasma frames take like no time instead of stressing
> the HDD for seconds and quite reduces the startup time of the
> desktop shell - even in a running session.
More information about the kde-core-devel