Compilation and RAM usage FAQ

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
User avatar
semireg
Posts: 14
Joined: Mon Dec 18, 2017 3:53 pm

Re: Compilation and RAM usage FAQ

Post by semireg » Tue Dec 19, 2017 5:26 pm

I think I have the same general question as OP... but perhaps my question needs a new thread.

I've been working on a ESP8266 project for a week and running out of RAM has been challenging. I've read the links often cited, and used the workflow of moving mostly debugged files into the modules dir for freezing. However, I'm still running out of space.

What would be most interesting to me is some kind of memory tutorial that shows what parts of our code relates to the symbols in meminfo(1). I know there's a legend, but what does tail/head mean and how does it relate back to lines of python? How do you read everything on the stack or heap? Do the stack/heap change size based on the amount of code I'm freezing in modules? Perhaps users would benefit from a tutorial that demonstrates extremely poor code and how it displays in meminfo(1)?

I feel like my questions are worded wrong - but hopefully you get the idea of where I'm coming from (iOS/Android/Linux development where this is all abstracted away into gigs of RAM...)

Btw, since this is my first post - thank you to this community. It's been utterly fascinating.

(as an aside, on my unix port when I issue meminfo(1) and gc.collect() repeatedly it starts to fragment memory. :shock:)

jickster
Posts: 629
Joined: Thu Sep 07, 2017 8:57 pm

Re: Compilation and RAM usage FAQ

Post by jickster » Wed Dec 20, 2017 7:42 pm

semireg wrote:
Tue Dec 19, 2017 5:26 pm
(as an aside, on my unix port when I issue meminfo(1) and gc.collect() repeatedly it starts to fragment memory. :shock:)
I think the more you use gc.collect(), the less chance the memory becomes fragmented.
It would be nice to have gc.defragment()

User avatar
deshipu
Posts: 1346
Joined: Thu May 28, 2015 5:54 pm

Re: Compilation and RAM usage FAQ

Post by deshipu » Wed Dec 20, 2017 8:14 pm

De-fragmenting memory would require moving some of it around. To do that, the garbage collector would have to be able to modify the pointers that it found. To do that safely, it would have to be sure that any "pointer-like data" it found indeed is a pointer (right now that's not the case, there are false positives). To do that, would require additional memory to somehow mark or keep a list of pointers.

Post Reply