apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Wed, 06 Jun 2001 14:29:20 GMT
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 Woolley
   Charlottesville, VA

View raw message