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

Re: delta combiner sloooooooowwwwww

From: Branko ÄŒibej <brane_at_xbc.nu>
Date: 2005-02-10 12:30:03 CET

Branko ÄŒibej wrote:

> Florian Weimer wrote:
>
>> * Branko ÄŒibej:
>>
>>
>>
>>> No, the delta combiner isn't slow. And your data seem to be skewed,
>>> as I get similar call counts but quite different timing results (I'm
>>> using an instrumenting profiler, not a sampling one). Running with
>>> current trunk, with both the WC and the repo on a RAM disk,
>>> measuring only svnserve and ignoring network I/O I get this for rtl.h:
>>>
>>
>>
>>
>>
>>> svn_fs_bdb__string_read 17273 0.05 17.12
>>>
>>
>>
>> I believe Daniel is using the FSFS backend. Maybe this explains the
>> difference?
>>
>>
> There's not all that much difference. I think the problem is that
> rtl.h is way too simple a test. Sigh...
>
> I'll run tests on FSFS with combine.c now.

And indeed...

Function Calls F% F+D%

svn_txdelta__compose_windows 19359 0.76 72.87
copy_source_ops 447007344 17.91 68.37
search_offset_index 894014688 43.07 43.07

The really horrible bit are the timings (in microseconds)

Function Average Min Max

svn_txdelta__compose_windows 47.17 0.07 297.67
copy_source_ops 0.05 0.04 308.98
search_offset_index 0.06 0.01 0.07

This shows that the index xearch is fairly stable, but copy_source_ops
is not. Note that about 95% of all calls to copy_source_ops come from
the recursion.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 10 12:32:19 2005

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.