Return-Path: 
 <dev-return-2444-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 55347 invoked by uid 500); 6 Jun 2001 14:49:42 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 55235 invoked from network); 6 Jun 2001 14:49:26 -0000
Date: Wed, 6 Jun 2001 16:48:16 +0200
From: Luke Kenneth Casson Leighton <lkcl@samba-tng.org>
To: Cliff Woolley <cliffwoolley@yahoo.com>
Cc: new-httpd@apache.org, dev@apr.apache.org
Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18
Message-ID: <20010606164816.X7921@angua.rince.de>
Mail-Followup-To: Cliff Woolley <cliffwoolley@yahoo.com>,
	new-httpd@apache.org, dev@apr.apache.org
References: <20010606010429.Y23560@lyra.org>
 <Pine.GSO.4.32.0106061017110.8282-100000@cobra.cs.Virginia.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <Pine.GSO.4.32.0106061017110.8282-100000@cobra.cs.Virginia.EDU>;
 from cliffwoolley@yahoo.com on Wed, Jun 06, 2001 at 10:29:20AM -0400
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

what's the profile of the memory allocation / reallocation / deallocation
like?

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
decisions.

luke



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
>    cliffwoolley@yahoo.com
>    Charlottesville, VA
>