Re: 1.1rc1 performance regression in 'svn status' (and also 1.1rc2)

Matt Doran <mattdoran@bigpond.com> writes:

>> 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.

Does it make sense for to look for a suitable xlate handle in the
parent pools before falling back and creating a new one in the current
pool? If such a handle is found it could be stored in the current
pool so that the search would only occur once per pool.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org