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.
