> From: Greg Hudson [mailto:ghudson@MIT.EDU]
>
> I don't have any problems with this patch, but... isn't APR's pool
> system doing way too much work? If I were implementing it, I would
just
> malloc() a new block for each apr_palloc(), chain it into a list, and
> free() all those blocks when the pool is cleared or destroyed.
>
> Presumably the extra work is for some theoretical or actual
performance
> gain, since Apache is very performance-sensitive. Have people
actually
> measured a performance benefit from the current code over the dumb
> implementation?
>
> (Apologies for, most likely, treading on well-trammeled ground.)
The performance gain by not having the pools free memory is well
measured and understood. The thing is that most (if not all) long-lived
processes eventually will reach a steady-state with regard to how much
memory they need. By not calling free() from within the pools code, we
allow ourselves to reach this steady-state, and never again call
malloc() while processing a request. This means that the cost of the
original malloc() can be spread over EVERY request that the child
process handles, which is a serious performance boost.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 22 19:50:17 2002