apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES include/apr_pools.h memory/unix/apr_pools.c
Date Mon, 14 Apr 2008 20:44:09 GMT


On 04/14/2008 10:05 PM, Sander Striker wrote:
> On Mon, Apr 14, 2008 at 9:43 PM, Joe Orton <jorton@redhat.com> wrote:
>> On Sat, Apr 12, 2008 at 08:42:59AM -0000, Mladen Turk wrote:
>>  > Author: mturk
>>  > Date: Sat Apr 12 01:42:51 2008
>>  > New Revision: 647394
>>  >
>>  > URL: http://svn.apache.org/viewvc?rev=647394&view=rev
>>  > Log:
>>  > Introduce apr_pool_sys_allocator_set
>>
>>  Why can't you just use a custom allocator for whatever the problem is
>>  here?  That's what the allocator abstraction is *for*, right?  Adding
>>  yet another abstraction above the allocator seems really wrong;
>>  especially since it introduces a bunch of global state and *everybody*
>>  suffers the overhead of the additional function calls and conditionals.
> 
> Indeed.  We went through quite a few iterations of performance testing
> and tweaks to get to where we are.  Note that we introduced a memory
> allocation system with more abstractions before... we punted on that once
> we found out when it caused too much overhead.

But now that we have branched 1.3.0 we have to live with it until 2.0, right?
Maybe branching just 48 hours after these commits wasn't such a good idea
especially with these 48 hours being a weekend after ApacheCon.

Regards

RĂ¼diger



Mime
View raw message