> From: Greg Hudson [mailto:[EMAIL PROTECTED] > > 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
