Stefan Fuhrmann <stefan.fuhrm...@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*
