Re: ra_dav compression question

Chris Hecker wrote:

>
>> Quite a lot, actually. The last numbers I got are that we're within 10%
>> of "diff -e | gzip -9", and we'll beat that consistently once Dan
>> Berlin's svndiff patch goes in (i.e., once I get the time and
>> inclination to finally bring it up to date).
>
>
> That's good. Is it run on adds?

I don't believe so; I'm not too familiar with that part of the code.

> How is that compression ratio possible unless you're actually doing a
> real compression (not just diff/delta)

We are doing real compression; it's part of the vdelta algorithm.

> on it in the first place, and if you are, then why would you want
> SetOutputFilter on there anyway (since you'd risk bloating from
> double-compression, maybe, or at the very least wasting cpu trying to
> compress it again)?
>
>> Yeah. And I'm wondering if compressing our delta stream is really worth
>> the effort.
>
>
> Indeed. Has anyone checked to see whether using mod_deflate is a lose
> from recompressing in the first place, if it's that well compressed
> already?

It would be interesting to measure that, yes. New data (from checkouts
and added files) would definitely benefit from mod_deflate, at least
most of the time. Then there are all sorts of XML reports that compress
really well.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org