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

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

> - Have a global hash with mappings from handle name (identifying the
> translation) to a linked list of xlate handles.
> - When you want to translate:
> . Lock a mutex.
> . Look for a handle in the hash. If one is found, remove it from the list
> and use it.
> . If no handle was found, create one.
> . Unlock the mutex
> . Use the handle.
> . Lock, put the handle back into the list and unlock.

Just make sure you add/remove from the list without allocating memory,
otherwise the memory use will grow without bound. Allocating memory
per handle is OK, allocating memory per use of a handle is not.

> This avoids having the lock held during the translation. It will create as
> many handles as is needed simultaneously and destroy them at program
> termination.
>
> It would be simpler to just have one handle per combination of to/from
> encoding, but as Greg pointed out, this might give to much contention on
> the translation lock, especially since we do a lot of translations during
> our WC crawling commands.

It's notoriously difficult to predict thread contention accurately.
However, instinctively I prefer your other design, the one that
provides per-thread xlate handles, assuming it can be implemented
correctly.

> Comments/flames/... Maybe we just hve to give up on this one?

One report had "svn st" more then 10x slower on a large wc, that's
1.0.x compared to 1.1.x on win32. I'm glad I don't use Windows!

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