[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: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-08-13 17:58:19 CEST

"Peter N. Lundblad" <peter@famlundblad.se> wrote on 08/13/2004 01:56:08
AM:

> On Thu, 12 Aug 2004, Greg Hudson wrote:
>
> > 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. 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.
> >
> This was discussed earlier on this thread. If a pools parent is in a
> different thread, this will not work. You can't use a xlate handle in
> different threads at the same time, AFAICK.
>

How would svn st be running multi-threaded? Aren't client ops always
single thread? Or is this a general routine used in other cases as well?

Is there a simple way to check if there are multiple threads running so
that it could use the xlate handle when running client operations?

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 13 17:58:26 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.