Web lists-archives.com

Re: cache is big space waster

Felix Miata posted on Tue, 06 Dec 2016 22:50:39 -0500 as excerpted:

> # df /
> Filesystem     1K-blocks    Used Available Use% Mounted on /dev/sda12   
>    5655093 5090409    277965  95% /
> -rw-rw-r-- 10547304 Dec  6 22:36
> /var/tmp/kdecache-user1/icon-cache.kcache -rw-rw-r-- 84377704 Dec  6
> 22:35 /var/tmp/kdecache-user1/plasma_theme_default_v2.0.kcache
> -rw-rw-r-- 84377704 Dec  6 22:35
> /var/tmp/kdecache-user1/plasma_theme_internal-system-colors.kcache # rm
> ( 3 .cache files above )
> # df /
> Filesystem     1K-blocks    Used Available Use% Mounted on /dev/sda12   
>    5655093 4914616    453758  92% /
> Do cache files that big actually offer any real world performance
> advantage?

In your case it appears, based on the identical size for two of the 
files, that you *might* have two copies of the same file.  It might be 
worth running diff or md5sum/sha1sum/etc on them to see if they are 
indeed identical files.  I run a different theme here (smoothx, 
downloaded from kdelook.org), but I don't have that duplication, and my 
theme cachefile size is rather smaller, ~16 MiB vs your 80+ MiB, as well.

Meanwhile, taking a look at those files with a hex(idecimal) aka binary 
file viewer/editor is... educational.

As mentioned above, my theme-cache file is smaller, ~16 MiB vs your 80+ 
MiB, while my icon-cache file is roughly the same 10+ MiB in size.  Based 
on the paths and filenames in both files, they appear to be binary caches 
of various graphical elements, primarily png files, used to create the 
theme.  The idea behind caching them is presumably to serialize them into 
a single binary stream in one file, where they can be read at plasma 
startup far faster than reading individual files that may be located all 
over the filesystem, one at a time.

So far so good, and I agree with the general idea.

But the *surprising* thing when just now looking at mine in a hex viewer 
is just how much of that "cache" is entirely empty, consisting entirely 
of null-bytes.

On mine anyway, the last actual non-null byte in the ~16 MiB theme-cache 
file is at roughly 14% into the file, byte 0x24400A or 2,375,690, of 
16,875,624.  The rest is all null-bytes, and that's just the empty space 
at the end of the file, not even including all the null-bytes between 
various cached pngs, etc.

OK, so say they're using some format that needs to be some even size, 
perhaps some factor of two of a standard memory page size (4K on x86/
amd64, 64K on some archs).  But that's under 3 MiB so would round up to 4 
MiB in size, with "only" 1.6 MiB or so of wasted null-buffer at the end.  
It'd still save over 12 MiB, ~3/4 of the space that the current file 
takes up, with the rest all entirely empty null-bytes.

The ~10 MiB icon-cache file actually uses even less of its space, 5% or 
so, with the last non-null byte being 0x85379, 545,657.  OK, so using the 
same factors of two storage assumption, this one couldn't fit in half a 
MiB, but it could certainly fit in a 1 MiB file.  Why does it need 10 
MiB, with the last nearly 9.5 MiB of it entirely empty null-bytes?

Meanwhile, on my system, the system and /home are on ssd, while /tmp is 
on (the memory-backed) tmpfs, with my user's tmpdir being a symlink to a 
directory created on that tmpfs.  So here, those cache files get 
recreated on each reboot or drop to single-user-mode and umount of the 

And while I /am/ on ssd so my cold-cache regenerate-cache-files kde/
plasma startup time isn't going to reflect the experience of users still 
on spinning rust, I can say with perfect confidence that at least on my 
ssd, kde/plasma startup time isn't noticeably affected by having to 
regenerate those files.

Tho I do recall kde3 and early kde4/plasma, before I switched to ssd, 
taking noticeably longer to startup in cold-cache mode than they did with 
a kde/x restart, so I assume it would on plasma5 as well.

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman