[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 2226 - trunk/subversion/libsvn_delta

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-06-20 01:23:43 CEST

On Tue, 2002-06-18 at 12:15, Karl Fogel wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
> > On Sun, 2002-06-16 at 19:28, Karl Fogel wrote:
> > > The big question is, how much does it improve performance? Our big
> > > problem case was undeltifying files larger than the delta window
> > > size.
> >
> > Um, that problem case would have been due to a bug of some sort, not due
> > to the lack of a delta combiner.
> I'm not sure precisely what is being asserted or denied above :-).

My understanding is that, at some time in the past, it was observed that
if we deltified files above the window size, memory usage went through
the roof. That's clearly a bug; windows are there to place a ceiling on
memory usage, not make it bigger. I don't know if anyone has checked
whether this bug still exists.

A delta combiner shouldn't help much; the problem happened (I believe)
even if there was only one delta to apply.

> so my question can be
> interpreted as "Does it succeed in addressing the problems it is
> designed to address?"

It is designed to address performance problems when there are lots of
(smallish) deltas between the revision you want and a plaintext.
Without a delta combiner, an N-delta chain would take O(N*S) time to
undeltify, where S is the average size of the file. With a delta
combiner, it's O(N*D + S) time, where P is the average size of the

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 20 01:24:16 2002

This is an archived mail posted to the Subversion Dev mailing list.