Didier Kryn <kryn@???> writes:
> Le 31/01/2016 14:28, Edward Bartolo a écrit :
>> The question is how do memory managers succeed to remain efficient and
>> yet cope with memory allocation of so many different sizes?
>

>     I doubt they're efficient.

>

>     If you really need an efficient memory allocator - but do you
> really need? - then better write one fitted to your needs. A universal
> memory allocator cannot be efficient for all cases. On the other hand,
> if you can organize your application in such a way that you need to
> allocate and deallocate variables according to a simple scheme, then
> you can do it with perfect efficiency. Two examples below that I have
> experimented for my own use:

>

>     If all your objects have the same size, you can organize your
> buffer as an array.

[...]

If all objects have the same size, malloc is going to work very nicely
at the expense of (glibc malloc) adding 32 additional bytes (according
to comments in the glibc malloc.c file. Worrying about that is probably
not worth the effort. A more problematic (for some definition of
problematic) situation is when there are many objects of different sizes
and if objects whose size is identical have vastly differing
lifetimes. This introduces so-called 'external fragmentation' into the
malloc heap as a whole region of memory split into chunks of a certain
size can end up pinned down by a single, long-living object of this
size. This can consume a significant amount of memory for a long-running
program. Workarounds for that would be

    - limit the number of different allocation sizes used by a
          program by rounding each to a minimum value supposed to be
          large enough for a class of program allocation sizes in order
          to increase reusability of chunks

    - don't allocate short-lived objects on the malloc heap but use
          the stack for that wherever possible

But both only really make sense if there's more application code than
library code as library code will usually use malloc aggressively, IOW,
if you're using C++, just forget about the issue: Even a fairly simple
program will end up with several hundreds of M RSS and there's nothing
which can be done about that (minus not using most of the C++ standard
library).