On 12/11/12 11:49, Bogdan Harjoc wrote:
Alternatively, a "compact" operation could be run periodically, that
compresses the cache using the same approach.

Is cache size/capacity a very big issue for you?

Have you tried the CCACHE_COMPRESS feature? That simply gzips the binaries in the cache. You can control the compression level with CCACHE_COMPRESSLEVEL.

Or how about a larger cache limit? If you don't have much disk space then combining that with CCACHE_HARDLINK might provide a useful saving? (Although compression must be disabled and your cache must be on the same file-system as your build.)

My question is whether ccache's real-world use would benefit from a feature
like this. I can put together a test that looks through people's .ccache
and reports how many "good bsdiff candidates" there are, and what the
savings would be.

Any opinions ?

My opinion is that ccache is a space-speed tradeoff that moves the savings balance toward speed-savings and away from space-savings. For the most part, users are fine with that, indeed want that, and modifications that move that balance back toward space-saving aren't interesting.

This idea is nice, but seems like it will reduce performance on both cache-hit and cache-miss, like regular compression, but even more so, especially on cache-miss.

That said, if we can have out cake and eat it then bring it on. (It's a shame the hard-link feature isn't completely safe, or it would do just that.)

ccache mailing list

Reply via email to