Re: Finding out minimal allocation unit

[Stefan Bellon <sbellon@sbellon.de>]

Randy Brukardt wrote:

> Right, but that obscures your algorithm and makes it harder to
> maintain. It's better to write a storage pool that does the blocking,
> and does it behind the scenes. (Of course, if the overhead of "Next"
> is contributing to the problem, you might not have any choice.)

Ok, will have a close look at storage pools.

> But, honestly, I don't see why you're so concerned about getting the
> blocking factor exactly right. Just make it big enough so you're
> always allocating at least 256 bytes at a time, and relax. Unless you
> have a huge number of these structures, the possible waste of a
> couple hundred bytes per list item isn't going to make much
> difference.

Just an example, in one case of our tools, I replaced the simple linked
list with the above mentioned "b-list" and memory usage went down from
2500 MB zu 1900 MB. That's a saving of 600 MB. So, yes, we are
concerned about efficiency in memory storage as we come close to the 3
GB limit of addressable user space on 32-bit machines.

> So, in summary, if the insertion/deletion issues are really
> significant, then use a custom storage pool, and don't mess with the
> top-level algorithm.

Will do. Thanks for all the help and ideas!

-- 
Stefan Bellon