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

Re: [RFC] : full-text instead of vdelta against empty bytestream

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-11-05 04:09:18 CET

Greg Hudson <ghudson@MIT.EDU> writes:

> On Tue, 2003-11-04 at 17:48, C. Michael Pilato wrote:
> > > That may be the reason, but I don't think it actually speeds up read
> > > operations to use a plain text.
> >
> > Sorry, but I've read this three times, and I can't find an immediate
> > reason why this statement would be correct. I can only assume that
> > you mean that in the overall cost of hitting the database, perhaps the
> > additional overhead of reading from a delta-versus-empty-file is lost
> > in the noise?
>
> 1) As mbk points out, we'll be reading fewer blocks from the database.
> Undeltification is cheap; disk I/O is expensive.
>
> 2) If we're retrieving any revision other than the head revision, we
> already have to perform an undeltification operation. I think "combine
> N deltas and apply the result to plaintext P" is probably about as slow
> as "combine N+1 deltas and apply the result to the empty string."
>
> 3) If David succeeds in his work, we will save a deltification step for
> checkouts of the head, without having to sacrifice compression. Since
> deltification is relatively expensive, and checkouts of the head are
> common in many contexts, that's a big win.
>
> Actual measurements would be better than my speculations, of course.

Ah. Now, see, that's the kinda data that makes an otherwise
unintuitive claim seem quite rational! Thanks, Greg.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 5 04:10:19 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.