> On Sun, 8 Aug 2004, Brane wrote:
>>>
>>>SVN 1.0.6: ~ 4 secs
>>>SVN 1.1rc1: ~ 38 secs !!
>>>
>>>I used the Filemon utility from sysinternals to try to determine what it
>>>happening. It looks like 1.1 excessively hits 'iconv' files. (e.g.
>>>windows-1252.so, utf-8.so, etc)
>>>
>>>
>>I did some more checking in GDB. It appears that apr_xlate_open gets
>>called 4312 times out of 17204 calls to get_xlate_handle (in
>>libsvn_subr/utf.c).
>>This was during a run of "svn st" on trunk. This caching strategy needs to
>>be improved.
>>
>>
>That's a 75% hit rate, which -- given our constraints -- isn't all that
>bad. The problem is that we can only safely cache the xlate handle in
>the current pool. If that happens to be a subpool in some loop -- well,
>tough luck.
>
>>I don't know why it is faster on 1.0, though.
>>
>>
>We probably fixed some pool usage bugs in the meantime, and those fixes
>happened to narrow the scopes of some xlate handles.
So is that the answer on this one? There's nothing that can be done?
I've just installed the TortoiseSVN 1.1RC (built from svn 1.1RC2) and it's
showing the same behaviour. It takes 15-20 times longer to do a
status/commit on a large repository compared to 1.0.6. For a WC for a repo
with about 5000 files it takes ~40 secs at 100% CPU on a P4 1.8G. Not very
pretty, especially when it used to only take about 4 secs with 1.0.6.
FileMon still shows very aggressive reading of the iconv files.
Is anyone else out there experiencing this type of perf degradation on
windows? Could this be something peculiar on my box?
Thanks,
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 13 00:40:48 2004