[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: mark benedetto king <mbk_at_lowlatency.com>
Date: 2003-10-22 03:47:19 CEST

On Tue, Oct 21, 2003 at 10:57:20PM +0200, David Kimdon wrote:
> On Tue, Oct 21, 2003 at 12:16:04AM -0400, Daniel Berlin wrote:
> >
> > On Oct 19, 2003, at 6:55 PM, David Kimdon wrote:
> >
> > >Hi,
> > >
> > >The included patch removes vdelta calculation when we are sending the
> > >full text of the target.
> >
> > Except that vdelta against an empty bytestream will be quite a bit
> > smaller.
> true. I did a few tests and the vdelta against empty bytestream
> compresses data to about one half the original size. This makes this
> optimization only interesting to a rather niche market. Anyone who
> wants to lower CPU load on the producer and send more data would like
> it, but I'm not sure who would want to double the data sent.
> >
> > This should probably be controlled by some option, since it's not
> > always a win for everyone (it depends on your network connection speed,
> > etc)
> At this point I'm thinking if it isn't an all around win then it
> should probably not happen. I spent some time looking at trying to
> get some less CPU intensive compression that the consumer would still
> be happy with, but as Greg already pointed out, there isn't an obvious
> way of doing that.

I wish I could take credit for this idea, but Greg Hudson pointed out
on IRC that we could store the youngest revisions of files as deltas
against the empty bytestream.

Then there would be no CPU cost to the compression; it would be already
done, and the one-time-per-commit cost amortized over the many checkouts.

I think this would also cut down repository size, since the fulltexts would
not exist anywhere in the repository. The smaller size could conceivably
improve performance, since there would be fewer pages to read for certain
operations, higher chance that any particular page would be in cache, etc.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 03:48:06 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.