Re: On pool / memory usage debugging

Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:

> This post has been prompted by issue 4531 and r1643834
> (http://subversion.tigris.org/issues/show_bug.cgi?id=4531
> http://svn.apache.org/viewvc?view=revision&revision=r1643834).

> IOW, pool debugging is nice for tracing allocations but if you
> want to measure memory consumption on the OS side, turn
> pool debugging off.

I have been looking at the proposed 1.8/1.7 backport for issue 4531.
The problem is easy to reproduce with pool debugging enabled and the
patch does reduce memory use, but with a normal build I don't see the
excessive memory in the first place. The runtime of the copy is
similarly affected: it is negligible with a normal build but takes
several seconds when pool debugging is enabled.

Was this issue raised in response to a problem observed in a normal
build? Can the problem be reproduced in a normal build? Perhaps the
large tree produced by the script in the issue is not large enough to
cause the problem in a normal build?

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*