[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