On Fri, Mar 27, 2009 at 4:40 PM, Jim Jagielski <[email protected]> wrote: > > On Mar 27, 2009, at 11:17 AM, Mladen Turk wrote: > >> Jim Jagielski wrote: >>> >>> On Mar 26, 2009, at 7:51 PM, Justin Erenkrantz wrote: >>>> >>>> 2009/3/26 Branko Čibej <[email protected]>: >>>>> >>>>> Maybe it's just me, but all that seems like a monumental waste of time. >>>> >>>> If we can't beat the old system by COB tomorrow consistently, then I >>>> think we can simply revert it or we add tcmalloc as a compile-time >>>> option if it's not too complex to use that. >>> >>> Before we do that, why not spin off a dev branch of what we currently >>> have >>> so those of us interested in profiling can still do some work >>> on it... >> >> Sure, you can do that. >> >> The problem with design concept will however stay. >> apr_pool and malloc/free simply don't fit with each other. >> > > Well, kind of depends on what apr_pool actually is :) > > BTW: shared this with some of the team. Did a framework test > against httpd-trunk, apr-trunk and apr-1.4. Using apr-trunk > the test absolutely fell down when doing t/modules/dir > > The current thinking is that it's the whole subpool crud
The whole subpool crud? Can you clarify? Do you mean the "hierarchical lifetime management"? Cheers, Sander
