Re: BSDiff for cache objects

On Mon, Nov 12, 2012 at 3:39 PM, Andrew Stubbs <[email protected]> wrote:

> 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?
>

No but there is room for improvement. This could be optional, like a
CCACHE_COMPRESS that saves 99% instead of 40% when I routinely recompile 20
kernel branches, for example (v2.6.x, 3.0.x, 3.4.x, -git, -next, -ubuntu,
etc).

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

Adjusting cache limits to available space works, of course. This is the
kind of reply I was asking for -- what size/speed constraints do ccache
users typically face.

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

The offline approach won't affect cache-miss at all. In cache-hit cases, it
will add the cost of applying the patch.

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

I'll run some tests on my .ccache dir and post results once I have them.

Cheers,
Bogdan