Re: Finding out minimal allocation unit

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Stefan Bellon <sbellon@sbellon.de> writes:

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

Since memory allocation patterns are usually not completely
predictable, won't that mean, that (if don't allocated everything from
custom storage pools) the maximum allocation will have a certain
amount of statistical "jitter", i.e. will sometimes exceed the 3 GB
limit and your application will fail now and then --
that is, the application will be anreliable?

You would have to prove that 3GB is the absolute upper limit needed,
something really difficult to do when you don't controll ALL
allocation (as opposed to only this special list type).

Regards -- Markus