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 > [EMAIL PROTECTED] > Charlottesville, VA >
