Re: More diff performance notes

Greg Hudson <ghudson@MIT.EDU> writes:

> > Humor me --- why are we comparing ourselves with diff | gzip? Why
> > aren't we comparing ourselves with diff -ae?
>
> We are comparing ourselves to diff -ae | gzip; I'm just not always
> clear that I use those options. Not sure if that was the source of
> any confusion or not.

Sorry, I meant to say "diff -ae | gzip" vs. "diff -ae". It's `gzip'
that's the issue.

> It would be somewhat unfair to compare ourselves to diff -ae without
> gzip because diff doesn't compress its output and we do. And because
> it would be about as easy to "just use diff and gzip" as it would to
> "just use diff", if we can't get better performance using more
> advanced algorithms.

Well, the original goal, back in the spring, was simply to get solid
performance on arbitrary binary files, without too much code
complexity. It seemed to me that `copy/insert' algorithms were better
suited than `substring replace' algorithms for deltas that don't need
to be human readable. Xdelta was my first choice, but the
implementation seemed unmaintainable; vcdiff was simply the next thing
I found.

But the requirements were, simply:
- try out copy/insert
- solid performance on binary files
- easy to implement

So, as far as I'm concerned, your svndiff stuff is ready to go.

That said, I certainly *don't* want to discourage you from improving
your encoding. If we can match diff + gzip without spending any
cycles on gzip, that's awesome.
Received on Sat Oct 21 14:36:10 2006