How and what does (plasma theme) caching operate? / KSharedDataCache issue?

[Christoph Feck]

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
> 
> Questions:
> -----------------
> - 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 [1]
> whenever required [2] 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,
> Thomas
> 
> 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)
> 
> [1] or a memory keeping daemon
> [2] 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.