Daniel Berlin wrote:
>On Sat, 2005-02-12 at 03:45 +0100, Branko Čibej wrote:
>
>
>>Greg Hudson wrote:
>>
>>
>>
>>>I hadn't read part of the "make blame even faster" thread when I sent
>>>this. Having read it, I have one addendum:
>>>
>>>On Thu, 2005-02-10 at 13:08, Greg Hudson wrote:
>>>
>>>
>>>
>>>
>>>>(Obviously not before 2.0, but I'm not sure if we can
>>>>realize any of these benefits before 2.0.)
>>>>
>>>>
>>>>
>>>>
>>>As people pointed out in that other thread, we can realize the "faster
>>>delta combiner" benefit before 2.0, and it may be worth changing to
>>>xdelta in 1.2 in order to do so. My biggest concern is that FSFS
>>>repositories with very shallow file histories may become significantly
>>>larger, since we will lose all self-compression. Perhaps we can
>>>continue using vdelta for self-compression in FSFS? I'm not sure how
>>>much of the speed win (if any) we'd be giving up by doing that.
>>>
>>>
>>>
>>>
>>If we use vdelta strictly for self-compression of the first revision of
>>a file in FSFS, it shouldn't be a problem. That delta would always be
>>the last in any chain of combinations, but because the self-compressed
>>vdelta doesn't contain source copy ops, the combiner should behave nicely.
>>
>>
>
>I actually tried this.
>We still get a very large amount of copy_source_ops time according to
>oprofile (though a factor of 5 or 10 less than you do with vdelta every
>revision).
>
>This was with vdelta only used when source_len == 0
>
>I tested this with two repos. One where vdelta was enabled if source_len
>== 0,and one where vdelta was not enabled for sotring to the repo, but
>was for compressing fulltexts that went over the wire (through a small
>hack to add an argument to compose_window, and disable vdelta for the
>tpush_* call to compose_window, which is only used by fsfs when storing
>to the repo).
>
>I verified that vdelta was happening only during over-the-wire transmits
>by aborting if it triggered vdelta, doing a repository load to make sure
>it didn't happen during that, and then making sure it *did* abort when i
>did a checkout or something that was going to send fulltexts.
>
>No clue why the combiner still behaves badly but i can provide you with
>repos and patches to reproduce.
>
>
Like I said on IRC, it's because I was wrong... the vdelta would be the
first in the combination chain, and it's full of target copies, so it
triggers the O(n^2) in the combiner from the start.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 12 20:19:16 2005