Greg Hudson <ghudson@MIT.EDU> writes:
> To summarize, on our repository, the effect of this skip-delta
> implementation is:
>
> * Load times: Up 5%
> * Dump times: Down 30%
> * Day to day operations: Drowned in the noise
> * Repository size: Up 5%
>
> Of course, with more extreme data sets, you get more extreme benefits.
> To show this, I artificially constructed a ~50MB "repository dump"
> where the repository consists of a single text file which shrank
> steadily from 3000 lines to 0 lines over 1000 revisions. With this
> repository, skip-deltas increased the load time by 17% but decreased
> the dump time by 94%, and the repository size still only went up by a
> small fraction.
>
> Here is the patch, for review. It's against branches/issue-531-dev,
> and should wait until the delta combiner is integrated into the trunk.
Hmmm. I hate to say it after the work you've done, but with these
numbers it's hard to see why Subversion should incorporate this
change. Increasing dump performance (a rare operation) at the expense
of code complexity doesn't seem like a good idea. It doesn't seem to
have much benefit to day-to-day operations, and applying any change to
the [un]deltification code increases the review burden and the risk of
data corruption. Why is this a good thing?
(The increases in load time and repository size seem insignificant, so
I'm not counting those as points againt skip-deltas.)
Of course you can construct a particular scenario where the
skip-deltas have an amazing performance impact; but then, one could
tailor a special scenario to make any given algorithm shine, as you're
well aware. It's the behavior in common cases that really counts, and
in that respect skip deltas don't seem to help much.
Am I missing something? I haven't looked over the patch; if you feel
it actually makes the code *simpler*, or brings some benefit I haven't
noticed, then that's different. Just based on the above, though, I
don't see how it helps us...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 27 02:15:07 2002