[boost] Memory Pool items

From: Mark Deric (laguna_at_[hidden])
Date: 2004-07-18 14:48:53

I have been studying Stephen Cleary's boost::pool template and its
subclasses with respect to using them for non-array based allocations in
our company's product.  We don't use many arrays that we need to
dynamically allocate or resize except at init time.  But we use lots of
map-like collections and shared_ptr-like objects.

Our use case is allocation of memory for individual objects varying in
size from tiny (8 bytes, the case of a minimal impl similar to
shared_ptr) to not so tiny (150-250 bytes, the case of comprehensive
state tracking of an individual TCP/IP flow).  In several cases, the
count of allocated objects can be in the 100,000-1,000,000 range.

Two items I've been thinking about:

1) The Guaranteeing Alignment doc's "convoluted example where the
requested_size is 7, sizeof(void *) == 3, and sizeof(size_type) == 5"
caught my attention.  The lcm approach yields 105 bytes per chunk
"wasting" 98 bytes per chunk, or 93% of the alloc.  This was not so
offensive in that it doesn't represent a practical use case of
significance.  But then, I considered a more common use case in which
the consumer's object only had a char[13] data member against an
lcm(sizeof(size_type), sizeof(void*)) == 4.  The char[13] comes from the
semantics of the consumer's app.  Here, the lcm method would be to alloc
a chunk size of 52; and better would be a chunk size of 16.  As a
practical matter, what regressions would be introduced if the requested
size were just increased to the next multiple of lcm(sizeof(size_type),
sizeof(void*))?  I get the theoretical issue of the next chunk not being
on a multiple of 13; but I can't think of a practical case where this
would matter.

2) The issue of the array allocation performance at O(free store size)
has me wondering whether the pool class should incorporate the "ordered
free list" semantics at all.  Maybe a separate class that uses a model
more like the Linux kernel model would be better (i.e., a tiering of
pages, page pairs, pairs of page pairs, etc.).  With allocated chunk
counts in the 10e5 - 10e6 range; use of the pool classes array semantics
could get nasty.

Just my two cents worth.  BTW, I totally enjoyed studying Mr. Cleary's
work; he, like most of the boost contributor's is lot's smarter than me.
 That's why, when we are working on building our catherdrals in app
land, it's great to have a resource like boost to check on the quality
of our bricks.  Thanks to all.

Regards,
Mark

-- 
Mark Deric
Director, Research and Development
Deepnines, Inc.
http://www.deepnines.com