apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Poor performance with new apr_pool
Date Fri, 27 Mar 2009 15:17:55 GMT
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.

We should however work on allowing the initial
allocator code to be resized. In theory with zero
size each apr_palloc would end in malloc call.
What's left is to effectively merge the memnode with
block_list and everyone happy :)


View raw message