"Ron" <[EMAIL PROTECTED]> 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. ;-) _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
