Re: Finding out minimal allocation unit

["Randy Brukardt" <randy@rrsoftware.com>]

"Stefan Bellon" <sbellon@sbellon.de> wrote in message
news:4ecee347d7sbellon@sbellon.de...
> Markus E Leypold wrote:
>
> > And I thought it would exactly be the extra padding the OP was
> > interested in?
>
> Yes, basically I'm interested in the padding which is inserted and
> wasted and which could be used without resulting in a larger allocated
> memory chunk.
>
> So, instead of doing:
>
>    type Cell1;
>
>    type List is access all Cell1;
>
>    type Cell1 is record
>       Next : List;
>       Item : Item_Type;
>    end record;
>
> We would like to do:
>
>    type Cell2 is record
>       Next  : List;
>       Used  : Natural;
>       Items : array (1 .. N) of Item_Type;
>    end record;
>
> Where N is chosen in a way that N is maximized without resulting in the
> whole Cell to require the next larger allocation size.

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

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. And if they're expandable
anyway, you're probably going to be filling them up. Remember, the actual OS
memory allocator on Windows allocates in 64K chunks -- I doubt you want to
use *that* size for blocking!

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.
And if they're not, just allocate decent sized blocks and don't worry too
much about the waste - it's inevitable unless you write your own storage
pool (tuning as you are trying to do will only work on a single compiler
version/target operating system version; any change to either is likely to
change something - everyone is forever fiddling with their heap
implementations to improve something or other).

                                  Randy.