Pybricks, MicroPython, and Garbage Collection

[devinbreise]

I tried to take a look at gc performance on an EV3 today, only to discover that gc.set_debug() doesn't appear to be a part of the MicroPython implementation as seen here and here. The good news is that it appears possible to enable/disable and force collection when you want, nice things to have for embedded controllers written with a GC heap...

Do you happen to know if a window into the GC performance (how often it is running, ellapsed milliseconds, etc.) is possible in this environment?

[laurensvalk]

On EV3, pybricks-micropython is very similar to the unix port.

It has the GC debug print disabled by default: https://github.com/micropython/micropython/blob/master/ports/unix/gccollect.c#L167

When we publish the source, you can enable it and build from source, then run it in the same way you've already tried a custom build.

[laurensvalk]

Actually, since you helped us so much, here is that build just for you 😄

pybricks-micropython-v2.0.0b6-with-gc-print.zip

[laurensvalk]

I tested to make sure it worked with this script - normally something you wouldn't want to do:

from pybricks.media.ev3dev import Image, SoundFile

while True:
    test = Image(ImageFile.NO_GO)

[devinbreise]

THANKS! 😄 I'll play around with it early next week (along with the line follow) and publish here what I find.

[devinbreise]

This worked great. When I develop some longer test cases, it will be interesting to examine the memory consumption. Performance issues related to GC activity do occasionally rear their head on the Java platform for higher levels of FIRST robotics, especially when it comes to image processing for computer vision tasks. It might be nice to have the option in Pybricks to enable output of the gc stats so if folks suspect something, they can easily pursue the theory. I'd probably give the FLL teams I coach a very quick overview of GC, advise they call collect() before launching each "run", and then not worry about it until and if they see odd behavior that can't be explained with more obvious reasons.

[laurensvalk]

Thanks for the input. Though before worrying too much about it or advising others to explore it, it would be interesting to investigate if this could even come up in FLL-like situations. And if so, whether it poses a problem. The EV3 has a ton of memory, especially compared to other LEGO hubs, including SPIKE Prime.

Before we know, we'd create an FLL myth where everyone calls GC commands or teams blame it on the GC if something goes wrong, neither of which are recommended :)

[devinbreise]

Excellent point about not creating more myths! Today I had the chance to give Pybricks a better workout by stitching together about 40 seconds of FLL activity. I called the GC at the end of each one of these "runs" and noticed that the memory used by the run varied from ~40-160K. Nearly all of which was recovered by the collect() at the end. Regardless, as you say, this is a drop in the bucket for an EV3, so I wouldn't expect to see this impact FLL teams in a meaningful way.

However, for educational purposes, I would still advocate for including the ability to get the stats in the production release if there is no particular cost to that.

[laurensvalk]

Thanks for sharing, interesting to see the values for a typical FLL run - also because we are bringing Pybricks to platforms with less RAM.

I'm afraid we can't enable the statistics in the main build however, because right now that would mean it would print whenever the garbage collector runs, which may result in unwanted printing in the program output (or worse, a delay because it takes some time to print).

It is also a piece that sits outside the Pybricks code, so accessing the stats as a feature might be a request for upstream Micropython instead.