apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Striker <s.stri...@striker.nl>
Subject Re: Poor performance with new apr_pool
Date Fri, 27 Mar 2009 16:04:26 GMT
On Fri, Mar 27, 2009 at 4:40 PM, Jim Jagielski <jim@jagunet.com> 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 <brane@xbc.nu>:
>>>>>
>>>>> 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

Mime
View raw message