On Wed, 1 Sep 2004, [UTF-8] Branko Ä^Libej wrote:
> lundblad@tigris.org wrote:
>
> >Author: lundblad
> >Date: Tue Aug 31 14:20:47 2004
> >New Revision: 10788
> >
> >Modified:
> > trunk/subversion/include/svn_utf.h
> > trunk/subversion/libsvn_subr/cmdline.c
> > trunk/subversion/libsvn_subr/utf.c
> >Log:
> >Fix issue #2016. Cache UTF8 translation handles in a global hash table
> >instead of in the current pool, which improves performance, especially on
> >Windows.
> >
> >
> Apart from a bug that breaks compilation on (at least) FreeBSD, which I
> suspect is caused by using "#ifdef APR_HAS_THREADS" in some places
> instead of consistently testing with "#if"...
>
Thanks for analyzing this. Fixed in r10796.
> I think there is a better way to do this, that could avoid using global
> data and locks: add the xlate cache to the svn_client_context_t struct,
> and document that this structure is thread-specific. Most public
> functions need to grow a thread-specific context parameter anyway,
> although that will have to wait for 2.0. But I think it should be
> possible to use the cache from the context in most places where we do
> charset conversions now, by adding a set of conversion functions that
> take a context parameter.
>
I don't agree. How would libsvn_wc get the client context? IN the st case,
most of the translations are related to converting filenames. So you would
have to push the context down to the svn_io functions for this. An svn
context could be a good design for 2.0, but it doesn't solve the current
problem. Note that I'm talking about actual calls, not call sites in the
code.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 1 21:04:54 2004