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

[Thomas Lübking]

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?
   -> Should the cache be split up into "required by everybody" (frames  
etc) and "likely required by the desktop only" (clock, calendar, whatnot  
else)

- (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?)

- 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

- 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.