~/.cache/kdevduchain size

[René J.V. Bertin]

On Monday January 04 2016 14:17:38 Sven Brauch wrote:

>Yes. You can remove the whole .cache/kdevduchain and nothing will
>happen. Just don't do it while kdevelop is running, or it will likely crash.

Yeah, at the least it'll assert, which for all practical purposes is the same as crashing :)


>*grin*
>echo $(pwd) |grep $(kdevelop -l |grep running |awk -F'{' '{print $2}'
>|awk -F'}' '{print $1}')

Oh, yeah, easy-peasy!

>Not aware of any ... and I'm not sure about the hit the whole
>compression thing has on performance ...?

You mean the reference I made to ZFS/btrfs compression? The argument as I understood it is that CPUs can be fast enough to reduce the amount of data to be exchanged over a slow IO link sufficiently to shorten the IO duration by more than the time it takes to compress (and esp. decompress). 

Now, if you referred to my suggestion it'd probably be better for performance if the cached information isn't compressed on the fly, I have a return question. If that's not the case, why isn't compression already being used? :)
(ZFS's lz4 compression gives 2-3x size reduction.)

Is this an aspect where it could be considered to give the user a choice, for instance through an option to "zip" session cache dirs at exit (and unzip them at startup)?

>I'd expect the different itemrepository version numbers will cause the
>cache to be purged every time you do that, but I'm not sure.

If they use the same cache. But how would that work, those session cache directories appear to have random names, no?
Is there a map somewhere that keeps track in what session each project is open, and also maps session name to cache dir name?

Cheers,
René