httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Wed, 06 Jun 2001 14:48:16 GMT
what's the profile of the memory allocation / reallocation / deallocation

sander has written sma - smart memory allocator.

it basically allows you to have more control over the block
size etc for management etc of memory allocation / reallocation.

it's wrapped through the apr_sms memory API [i think!] so
you'd be able to use a different mallocator if you decided
you didn't like sma.  use the tracking sms, or even the
simple standard-lib (malloc/free/realloc) sms instead.

up to you: the sms API framework is there to allow you to
experiment and definitively make these kinds of development


On Wed, Jun 06, 2001 at 10:29:20AM -0400, Cliff Woolley wrote:
> On Wed, 6 Jun 2001, Greg Stein wrote:
> > Tough call. A POOL bucket is nominally "safer" than a HEAP bucket. But *IF*
> > we are careful to ensure the HEAP bucket gets placed into a brigade, then we
> > are guaranteed it will be tossed.
> >
> > That said, we've seen issues with malloc() efficiency in the bucket code.
> > Using a POOL bucket has obvious performance implications. But on the
> > gripping hand, we have the up-and-coming fast-malloc patches from FirstBill,
> > et al. Those patches could mean that efficiency will not be the
> > determination between HEAP and POOL.
> I've been somewhat involved in those discussions, and a patch is still a
> ways off, I think.  The less we can allocate on the heap, the better.  I
> seriously doubt that, regardless of what patch is finally applied,
> allocating on the heap will ever be faster than allocating into a pool.
> It might come close to as fast, but we're currently not even close, as
> we're all aware.  :-/  On the other hand...
> As long as you ap_save_brigade into the right pool in the first place, the
> double copying wouldn't be an issue, but there are probably cases where
> you can't know which is "the right pool".  So you're probably right that
> using a POOL bucket opens us up to special cases where multiple copies
> might be made (even POOL->parentPOOL->...->HEAP in a worst-case scenario,
> I imagine), so it's probably best to go with a HEAP bucket.  All the other
> bucket-morphings that copy into memory use HEAP buckets, so we might as
> well be consistent.  <sigh>
> --Cliff
> --------------------------------------------------------------
>    Cliff Woolley
>    Charlottesville, VA

View raw message