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

Greg Hudson <ghudson@MIT.EDU> writes:

> On Thu, 2004-08-12 at 19:01, Philip Martin wrote:
>> 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.
>
> Yes, I proposed the same thing at some point, though perhaps only over
> IRC.

Something like

Index: subversion/libsvn_subr/utf.c
===================================================================
--- subversion/libsvn_subr/utf.c (revision 10603)
+++ subversion/libsvn_subr/utf.c (working copy)
@@ -54,11 +54,19 @@
   /* If we already have a handle, just return it. */
   if (userdata_key)
     {
- apr_pool_userdata_get (&old_handle, userdata_key, pool);
- if (old_handle != NULL)
+ apr_pool_t *search_pool = pool;
+ while (search_pool)
         {
- *ret = old_handle;
- return SVN_NO_ERROR;
+ apr_pool_userdata_get (&old_handle, userdata_key, search_pool);
+ if (old_handle != NULL)
+ {
+ *ret = old_handle;
+ if (search_pool != pool)
+ apr_pool_userdata_set (*ret, userdata_key,
+ apr_pool_cleanup_null, pool);
+ return SVN_NO_ERROR;
+ }
+ search_pool = apr_pool_get_parent (search_pool);
         }
     }
 
> That, possibly in addition to a few strategic calls to a new
> function which deliberately places an xlate handle in a pool, would
> probably solve our problem.

I suspect svn_opt_args_to_target_array will be sufficient for the
command line client.

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