Re: [avr-gcc-list] Doubly Linked Memory Pool

[Joerg Wunsch]

"Ron" <address@hidden> wrote:

> IMHO it seems to perform better than the existing
> malloc/realloc/free functions in the library, particularly at high
> fragmentation levels.

Btw., the current implementation has not been chosen to be as fast as
possible, but to use as little resources as possible.  This seems to
be what usually concerns people most.  So, for any allocated chunk,
two bytes overhead are needed to record the chunk's size, while no
link pointers are kept.  Once the chunk is freed, a link pointer is
placed into what used to be the chunk's payload before.

Obviously, doubly linked lists will perform better, no question.
(Also, I remember a suggestion to compact the existing code a bit, I
have to dig that up in my archives again.)

I've been thinking about the idea to offer different levels of a
malloc() implementation so the users have a choice (as separate
libraries, similar to the printf and scanf choices).  Level 1 would
then be avr-libc's historic implementation which was very simple but
prone to fragmentation, yet for someone who just wants to allocate and
free chunks of the very same size, it would save quite a bit of code.
Level 2 could then be the current implementation, and I can imagine of
your implementation becoming level 3: it needs even more resources (at
least in terms of RAM overhead), but performs better.  Obviously, that
would require that it is 1) a plug-compatible replacement, and 2) can
be made available under the established avr-libc licensing terms.
(Maybe a bucket implementation could also be a candidate, as they are
typically used in modern OS's memory allocators.)

As Eric said, if you're interested, avr-libc-dev is the more
appropriate list to discuss that.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)