On Mon, Nov 12, 2012 at 3:39 PM, Andrew Stubbs <a...@codesourcery.com> 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 _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
