using gc.collect()

[beetlegigg]

I see that using gc.collect() can show it freeing up a large chunk of RAM. I also know that the gc freeing up of RAM happens automatically. If the next function or module in one's code is going to use a big bite of RAM, more than that showing as available with gc.mem_free(), will micropython automatically run is automatic gc before running the RAM gobbling code or is a gc.collect() required?

To put it another way - is doing a gc.collect() before running the RAM gobbling stuff just a case of speeding up the loading and running of this code, whereas relying on the automatic gc to work will just mean the RAM gobbling code is may be somewhat slower to get up and running?

Thanks for any education and elucidation that may be given :)

[kjm1102]

I've never had much luck with inserting gc.collect() into my code. Running out of ram is a real time waster, I find it better to use a board with more ram or run the .py as a .mpy to if you need to stick with a particular board.

[robert-hh]

gc.collect() is run automatically when a request for RAM cannot be served, unless this mechanism is switched off. gc.collect() frees up memory blocks which are not in use anymore and tries to combine them with adjacent free areas, but is does not move used memory blocks. That may lead to the so-called memory fragmentation situation, that there are many free small areas in RAM, and a request for a large amount of RAM cannot be served, even if gc.mem_free() tells, that the total amount of free RAM is sufficient. calling gc.collect() frequently serves for two purposes:

• trying to avoid memory fragmentation.
• shortening the time an automatic tgc.collect() would need.

The deliberate call of gc.collect() would be placed in the code in situations which are not time-critical. There are tons of books and papers about memory management, but no method can squeeze a gallon out of a pint.

[cve2022]

* trying to avoid memory fragmentation.

* shortening the time an automatic tgc.collect() would need.

This is where careful software architecture comes to the rescue. I come from development mostly in C but also in C++ in embedded systems. For the former, using malloc()/free() is anathema (almost as sinful as using goto) , wheres for the latter, new()/delete(). It turns out their use is fine during the program startup (FTM there are cases where goto also leads to better code), instead of preallocating the variables statically (the traditional approach). Not using malloc()/free() and especially new()/delete() in the case of C++ during runtime is pretty inconvenient, but it is the price to be paid to benefit from the productivity they offer compared to Assembly. There are workarounds, e.g., when dynamic allocation is needed, pools of fixed blocks are used and some RTOSes provide them in their libraries.

I would adopt a similar approach with MP programs, build the objects that require big chunks of contiguous memory (thought not only them, for efficiency) during the program startup and passing them as arguments to their client objects. I acknowledge there may be better ways to do it I am not aware, though.

[jimmo]

@beetlegigg As already explained above, the GC will run automatically when necessary. However this is not always the optimal time to run as there may be many live objects.

The easiest "win" is to use gc.threshold to force earlier collection. https://docs.micropython.org/en/latest/library/gc.html#gc.threshold

The main piece of advice I give is to design your application in a way that:

• Minimises the lifetime of objects. (i.e. don't allocate something, then do a bunch more work in the same function after its no longer needed). The best way to do this is to break your code into smaller functions such that things go out of scope.
• Explicitly structure your application such that there's an obvious point to manually call gc.collect() when the most benefit will be achieved. e.g. if you application does something continuously in a loop, then call gc.collect() at the start of the loop.

[Ajb2k3]

I've put gc.collect() as the first line in my primary loop for MQT problems and for me it works but I have seen cases where someone running my exact same code on exact hardware still had mom issues.