apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@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:05:13 GMT
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.

Cheers,

Sander

Mime
View raw message