[darcs-devel] Compressing Patches, LZO, and that .gz.
Ralph Corderoy
ralph at inputplus.co.uk
Sat Apr 16 11:28:58 PDT 2005
Hi David,
> On Sat, Apr 16, 2005 at 02:18:46PM +0100, Ralph Corderoy wrote:
> > I thought decompression does account for quite a bit, escpecially on
> > commands where it has to go through lots of patch files. That's why
> > some people uncompress them all on disc, no?
>
> I haven't tested recently, but I think the main reason to use
> uncompressed patches with large repositories is to enable mmap, which
> makes darcs behave better under memory pressure. If you're not in
> danger of swapping, I don't think it'll make a big difference. But I
> could be wrong. The easy way to test would be to time darcs with and
> without compressed files. If you can't find a scenario where
> uncompressed files are faster, I doubt that a faster compression
> scheme will help (although this won't have been proven).
Good idea. I've used `darcs opt --[un]compress'. There's 2796 patches.
The test command is `darcs changes Add.lhs'. I ran it twice for both
compressed and uncompressed.
Compressed
37.290 user 36.000u sys 1.290s
37.600 user 36.470u sys 1.130s
74.890
Uncompressed
32.890 user 31.750u sys 1.140s
32.290 user 31.540u sys 0.750s
65.180
So compression uses ~ 15% more CPU time. lzop saving 40% of that would
mean it uses 9% more instead. Or, from the other side, about a 5.2% CPU
time saving from switching from gzip to lzop on something that reads all
the patches.
> Timings weren't conclusive as to which was faster, but that was enough
> to make the point--that zlib compression doesn't really slow things
> down much.
Fair enough.
Cheers,
Ralph.
More information about the darcs-devel
mailing list