4 ms·
> Dynamic allocation reduces the memory footprint, the author compares it to the best alternative which requires pre-allocation of a large chunk of memory. Arc
by dvt 4y ago
> Dynamic allocation reduces the memory footprint, the author compares it to the best alternative which requires pre-allocation of a large chunk of memory.
Architecturally speaking, it makes almost no sense to have dynamic memory allocation in Microvium. You could theoretically even do static analysis on whatever chunk of code you're about to run and figure out exactly what your upper bound for memory usage would be. (Remember, we don't have an interactive runtime.)
So now that I actually think about it more, not pre-allocating in this particular case is actually an antipattern.
- ricardobeat 4y agoThe author has a different perspective on that. From the article: > In typical firmware, idle memory is much more important than peak memory, as I explained in my last post. https://coder-mike.com/blog/2022/05/27/single-threading-is-more-memory-efficient/ https://coder-mike.com/blog/2022/05/27/single-threading-is-m...
- codermike 4y agoThe static analysis in Microvium does do this for the stack variables, but the heap is not bounded. It's trivial to write a for-loop or something that creates N new objects.