Just bringing this little dialogue into the public eye.
"Sander Striker" <striker@apache.org> writes:
> > From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> > Sent: 13 May 2002 02:08
>
> > I'm trying to piece something together here regarding Issue #622. I
> > did a checkout of a copy of the subversion repository's /trunk (at
> > revision 1600-and-something) over ra_local, with pool debugging turned
> > on, and watching the process in `top'. The `top' output showed the
> > svn process crawling steadily upwards in terms of memory usage,
> > finishing up at around 30M by the time my checkout completed.
> > However, the pool debugging output showed that we maxxed out our pool
> > usage at 2.29M. The pool debugging output *looks* accurate to me,
> > since the whole checkout process is a bunch of recursion and looping,
> > all of which is very "subpool-informed", and I've gone over this
> > process pretty thoroughly.
> >
> > What makes the actual footprint of the program so different in terms
> > of memory used? Are we leaking non-pool memory somewhere? Is the
> > pool code simply not re-using allocations?
>
> The latter is indeed the case. The production pools code does very
> little to reuse mem. It is a space-time tradeoff. There have been
> several patches to improve on mem reuse, but since there hasn't been
> a single project using pools that could benefit from these patches
> they've been lost in the archives. Maybe now is a good time to reevaluate
> patches that ensure better reuse.
>
> The reason Apache can get away with this is because apache has either
> shortlived pools or relatively small allocations. And ofcourse when pools
> were invented they were tuned for Apache...
>
> > I'd love to understand what's going on here. As is, the way the
> > ra_local checkout system is written, we *should* (I believe, unless
> > I'm missing something big) be seeing memory usage that's proportional
> > only to the greatest directory depth of the checkout. But I'm seeing
> > usage that is proportional to the number of items in the checkout
> > instead.
>
> Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 14 18:24:37 2002