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

Re: faster client pre-1.0: neon prefetching, multithreading

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2003-02-12 03:13:31 CET

On Tuesday, February 11, 2003, at 02:47 PM, Greg Hudson wrote:

> On Tue, 2003-02-11 at 14:31, Branko Čibej wrote:
>> Oh, but I think mod_deflate can do better than vdelta as far as
>> compression is concerned (well, slightly better)
>
> If we ever dusted off Dan Berlin's svndiff1 stuff, I think we would do
> about as well as gzip spacewise.

Yup.

> More importantly, though, would using
> zlib actually be any faster than using self-compressed vdeltas, if the
> goal is to speed things up?
>

You'd have to use zdelta or something (it's a delta algorithm based on
zlib).
zdelta *is* faster than vdelta.
Problems:
"
The zdelta internal buffer memory footprint is independent of the input
data size. The current version, however, requires that all the input
data is provided at once.
"
"The library, while debugged carefully, is not yet as stable as zlib
and at this point should not be used to compress critical data.
"
>> Yes, and a smart compiler probably already does that.
>
> svn_txdelta__insert_op is defifined in a separate source file. So
> nothing using the normal Unix build process will do that, because the
> information isn't available at the right time. (Unless you put off all
> compilation until the linking phase, anyway.)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 12 03:14:25 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.