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