Re: [PATCH] Fix memory leak like situation when parsing a svn_config_t object repeatedly

On Fri, 2005-07-29 at 01:57 +0200, Bernd Rinn wrote:
> >> Since creating a new pool adds overhead, I feel that the caller of
> >> svn_config_enumerate2() & co. should have a choice on whether an
> >> iteration pool is to be created or not. That's controlled by the value
> >> of the argument create_iteration_pool.

I agree with Julian that this is too many knobs. We normally create
subpools with impunity.

> The result is that pool creation increases execution times for a
> recursive read access check by 45%-100%.

That sounds bad on a first read, but how much time do we spend on
recursive read access checks relative to the other parts of the
operations that use them? authz checks are a memory-only operation, and
usually they're coupled with something doing relatively heavy I/O, which
is going to take much more time.

Regardless, if authorization access checks are dragging down our
performance in any practical way, the right answer is not to create
little performance-fine-tuning knobs, but to design a more efficient
representation for the authz file. I asked Dave to create an opaque
type for the authz file so that this can be done post-1.3 without
revving our APIs and changing the calling code.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 29 07:39:59 2005