apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jagunet.com>
Subject Re: Poor performance with new apr_pool
Date Fri, 27 Mar 2009 15:40:31 GMT

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

View raw message