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

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

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-08-15 23:42:54 CEST

On Sun, 2004-08-15 at 16:41, Peter N. Lundblad wrote:
> But the apr_pool_userdata_{get,set} isn't thread-safe just because we
> protect our uses by a lock. Other callers don't.

Right, sorry. I was imagining our specific userdata slot could be
protected this way, but of course it can't.

> I don't see a way to improve the performance via caching in pools. If we
> want to fix this, I think we need to add init functions and be able to
> detect if they were called. If this is problematic for 1.1 ( to which I
> might agree), then we won't fix this until 1.2. This will hurt TSVN users
> I think and that's bad because that's an important application on Windows.

I agree that we should solve this problem for 1.1, even at a high cost.

Let's introduce an optional initializer, but let's make it very limited
and specific. "void svn_utf_initialize(void);". We acknowledge that
it's a short-term hack. It can become a no-op in 1.x and can disappear
in 2.0.

I can think of three long-term solutions to free ourselves from this
hack:

  * Add a more general library initialization framework for this sort of
thing.
  * Invent the notion of a Subversion library context, like the
libsvn_client context but more opaque and general, and pass a library
context around to most or all svn library functions. This is the
"cleanest" solution, but it's also burdensome; callers already have to
pass around pools and exceptions. (We could fold the pools and/or the
exceptions into the library context to reduce the burden, but I'm not
sure that idea really pans out.)
  * Teach APR to handle statically-initialized onces.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 15 23:43:07 2004

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.