[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-08-13 12:04:37 CEST

"Peter N. Lundblad" <peter@famlundblad.se> writes:

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

I've reverted r10613. It's a pity, even on Linux I measured a 20%
speed increase running "svn st" on a large/deep working copy.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 13 12:05:02 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.