[daphreak]

"I have worked with a few embedded SDKs (by Microchip, Keil and Espressif), and all of them have a really dumb built-in implementation of the heap."

Many embedded systems allocate just once at startup and these "really dumb" implementations are completely sufficient. The vendors provide a fast, low-overhead solution by default and trust that developers can go find a more appropriate allocator if they need it for their application. Luckily we have many implementations to choose from!

[ithkuil]

I think the key contribution outlined in the post is the heap profiler tool that allows you to figure out whether you need a different allocator for your needs.

The tool can be found at https://github.com/cesanta/smart.js/tree/master/tools/heaplo...

If anybody knows other similar open source tooling, please share!

[dimonomid]

For the system that allocates just once at startup, I can't think of any noticeable change of performance even if allocator is 20 times slower. But, it should be memory-efficient, since RAM is really expensive on those devices, isn't it?

Standard allocators that I'm familiar with use minimum 8 bytes overhead per allocation. Umm_malloc uses 4 bytes overhead: twice less. If we have 200 allocations, it's 800 wasted bytes already.

Plus, it uses "best-fit" algorithm, so that the resulting fragmentation is far less than with the "first-fit", which is used in standard allocators. (if one really wants to, she can use "first-fit" on umm_malloc, too)

[m_eiman]

You also want to minimize Flash usage/code size; if your microcontroller has 8KB Flash, a more complex allocator might not be the best use of that Flash. Especially if you've got a allocate-once pattern.