Garbage Collection takes a long time (15ms instead of 1ms) and I am not sure what is causing the memory leak in the first place

[paulbuzzby]

Hi,

I have built a robot using an RP2040 Connect running the latest version of MicroPython. I posted a separate thread about the architecture a while ago here.

The issue I am facing is that while my robot's control loop is running, it consumes a consistent amount of free RAM per cycle. This causes the garbage collector to kick in every 70 cycles, which is very consistent.

This isn't a problem in itself, except that the collection takes 15-16ms to complete. The documentation suggests that this should take around 1ms, which would be completely fine. If I force garbage collection, it still takes 15-16ms to run, so the time taken to execute is independent of the free RAM available.

I thought the issue might be caused by the local variables I am using within various methods inside the classes I have created. I went through and made all variables part of the class __init__ function, so all variables within a class are referenced using self. However, after re-reading caching-object-references, it seems I shouldn't have everything at the class level.

Also, after going through this exercise, it made absolutely no difference to how much RAM is being consumed per cycle.

This leaves me with at least two questions:

1. Why is the garbage collector taking so long, and how can I reduce this time?
2. What factors within MicroPython could cause a "memory leak" that the collector needs to free up? I am confident that all variables used within a class are not being dynamically created.

I am still unclear whether MicroPython passes by reference or by value. Perhaps forcing a pass-by-reference approach could improve memory usage.

Thanks,
Paul

[scruss]

How long does your Update routine normally take? Longer than the 1/200 s periodic timer?

[paulbuzzby]

The update routine runs in 3-4ms if garbage collection doesn't kick in. I've lowered the tick rate down to 160 times a second. So there is headroom in the system when the update run. At least 2ms of headroom. I have experimented with lower tick rates as well. down to 80 times a second but this does not effect the garbage collection time.

separately, once I resolve this issue i want to push to up the tick rate but that is down on the list of issues at the moment.

[paulbuzzby]

Little bit of an update. I have found at least 1 leak.
When a float operation takes place 16 bytes of RAM gets consumed and not released until garbage collection runs. My code has a fair amount of float operations.

Is this expected?

As simple as

v = 2312123*123123123

vs

v = 2.312123*123123123

If you monitor free memory will see the second line consumes 16 bytes and its "Gone"

[corranwebster]

Not a Micropython memory expert, but a couple of things stand out:

• you have a timer interrupting every ~5 milliseconds and you are saying gc is taking ~15 ms; which means that your interrupt is certainly interrupting and running (presumably python code, which takes 3-4 milliseconds?) during garbage collection. It may well be that a lot of the 15ms of wall clock time that the gc is taking is spent running the update code.
• the notes on the Timer class (which you indicate you are using in your previous post) say that you shouldn't allocate memory during an interrupt: https://docs.micropython.org/en/latest/library/machine.Timer.html If you are allocating memory in the update method, and it is interrupting gc, then your code may be hitting bad or undefined behaviour in the gc.
• in Python and Micropython a lot of operations create objects (and therefore allocate memory) in ways that may not match your expectations coming from other languages. For example, when you call a method on an object (ie. foo.bar()) Micropython allocates a transient "bound method" object foo.bar. Similarly, Micropython will allocate temporary objects during mathematical computations. So it is easy to accidentally allocate memory.

So if my understanding of your situation is correct, I'd suggest:

• looking over your timer callback (the update method?) to make sure that it isn't allocating unexpectedly
• seeing if you can make your interrupt run quicker, or defer the time-consuming code to run outside the timer callback
• manually running the garbage collector (using gc.collect()) more frequently (so you get more, but faster operations) and when you know it is safe to do so (so it doesn't get interrupted).

Other comments which may help your mental model:

• "pass by value" and "pass by reference" are the wrong models to think of with Python parameters: variables do not refer to specific memory locations, but are instead names that can be flexibly assigned to objects. When you call a function, the parameters are just some new local names for the existing objects.
• when you perform an arithmetic computation the result (and any intermediate results) create new objects (possibly with the exception of small integer values? Not sure of the implementation details here, but I know CPython caches small integers). In C terms, the floating point operation allocates a small chunk of memory for a struct containing an object header and the actual floating point value to hold the result, and then points the variable at this new object.
• "regular" C Python uses reference counting so transient objects used in computations get garbage collected immediately; Micropython doesn't - those transient objects persist until the garbage collector is run

It may help diagnose your problem if you can give more detail about how your update method is scheduled and written.

[peterhinch]

"pass by value" and "pass by reference" are the wrong models to think of with Python parameters

To a point. numbers (ints and floats) behave very much as if they were passed by value - a local copy is made on the stack. The number in the calling scope is not changed. Objects (e.g. arrays) behave as if they were passed by reference: a local copy is not made and the object in the calling scope is subject to change.

[paulbuzzby]

Thank you. This is very helpful. I will do some more tests RE garbage times as it seems like the call to check for free memory also takes a bit longer than expected but i do need to see if the update loop is causing additional interruptions.

[peterhinch]

Floating point operations always allocate. To avoid allocation use small (30-bit) ints.

[robert-hh]

For short INTs, id(a) seems to return value*2 + 1, since the value is stored in the object and not a pointer to it's address.

[GitHubsSilverBullet]

Had to try it immediately. It seems as if it's possible to have two INT variables (a,b) with the same value to have the same id. Need to remember that.
Also, counting/incrementing would not generate a bunch of objects, thus being faster.
Thanks.

[robert-hh]

it's possible to have two INT variables (a,b) with the same value to have the same id.

That can be surprising I do not know if that is documented as difference to CPython.

[corranwebster]

it's possible to have two INT variables (a,b) with the same value to have the same id.

That can be surprising I do not know if that is documented as difference to CPython.

This is possible in CPython as well (for a different reason):

Python 3.12.7 (main, Oct  5 2024, 01:39:55) [Clang 16.0.0 (clang-1600.0.26.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 1 + 1
>>> b = 0 + 2
>>> id(a)
4348319472
>>> id(b)
4348319472
>>> id(2)
4348319472

CPython caches (or "interns") small little integer values for efficiency.

ETA: clarify that "small" is not the same "small" as Micropython.

[paulbuzzby]

I can see that uses int's will not allocate. As a silly question. Do I have to do something specific within the code to make sure it is allocated as a small int or is this suitable

tempA = 1234

[peterhinch]

@paulbuzzby

Is this expected behavior then that a float operation will consume free RAM that wont be released back until garbage collection is run?

Yes. This applies to allocations in general: they persist until the next GC. See this doc. The duration of gc.collect() depends on how much work it has to do. This can be minimised by regularly issuing a collection.

[rkompass]

It might be worth to add that this behaviour:

a float operation will consume free RAM that wont be released back until garbage collection is run

depends on the type of object representation MP is compiled with.

In this older discussion @jimmo clarified that:

Using object repr C means that floats are now not heap allocated and use the same inline representation we use for interned strings and small integers. This is a huge win for any floating point computation (because about half the time is spent allocating float objects). However this comes at a cost (you guessed it) the accuracy goes to 30-bit (instead of 32-bit), which is why we don't enable it by default. (I note that Arduino enable this on all their boards, e.g. Portenta, Giga, Nicla Vision, etc).

CircuitPython compiles with -O2 for all sources (MicroPython uses -Os and -O2 for some critical files), and it uses "object representation C" by default (MicroPython uses "D" by default).

The behaviour discussed above follows from MP being compiled with object representation D by default.
So it might be beneficial to try out object representation C not only for speed but also for avoiding/reducing garbage collection.

[dhalbert]

CircuitPython compiles with -O2 for all sources (MicroPython uses -Os and -O2 for some critical files), and it uses "object representation C" by default (MicroPython uses "D" by default).

It's true CircuitPython uses object representation C. As for -O2, we use it on some chips with plenty of flash, but as more native modules have been added over the years and we have bumped into flash limits, most ports now use -Os.

[paulbuzzby]

I am finding that the gc.collect() time is dependant on how much code is loaded. Regardless of the code actually running. If i just run gc.collect() then it runs sub 1ms but as i start to import modules the time to execute increases. Multiple executions, without executing code in between, do not result in faster execution times. There is a very subtle difference between the first execute time and then subsequent execution times. but executions times from the second execution are the same

1.719ms 1.539ms 1.528ms 1.527ms 1.528ms 1.528ms 1.527ms 1.529ms 1.528ms 1.527ms 1.527ms

Just as an example of the time difference between runs. All of the were executed one after the other.

This is the function being executed
`def GetGCCollectTimeTest() -> None :

start = utime.ticks_us()
gc.collect()   

end = utime.ticks_us()

print("{:6}ms".format(utime.ticks_diff(end, start)/1000))

return`

I can understand that the first execution would take an amount of time but if nothing has changed I don't understand why the time is so long for subsequent runs.

I need to dig deeper and it is no doubt based on the imported module requiring allocated memory.

[corranwebster]

As I understand it, MicroPython uses a mark-and-sweep garbage collector which means that it needs to visit every object on every gc call. The more objects in memory, the longer it will take, and it needs to start afresh every time.

In particular, your timing function is allocating objects (at least a float and a string) that will be garbage collected in the next call, so you aren't in a "nothing has changed" situation.

And yes, imported modules allocate not just the module, but every object (including classes and their methods) they define, so importing will increase the number of objects that need to be checked by the gc.