Reducing freeze time for gc.collect()

[jbrelwof]

gc.collect() freezes things for a sizeable chunk of time. How can that be improved?

• faster measurement
  • optimization without good measurements is... challenging
  • gc.mem_alloc() and gc.mem_free() are terribly slow - they use gc_info() (in C) to add up stats for each block in each mp_state_mem_area_t
    • adding a singleton to track the same info would add a little overhead in time for allocating and collecting instances, but would dramatically improve the speed of gc.mem_alloc() and gc.mem_free()
    • half of the hooks (allocation side) to do this appear to already be in place for the memorymonitor module, adding some tracking for frees during collection shouldn't be too difficult
• control when collection happens
  • gc.disable() and manually call gc.collect()
  • at least manages when the pause will be, but not how long it will be
  • would benefit greatly from faster measurement to determine when it needs to be done
• control how long collection takes
  • this is probably the most important improvement for getting things under control
    • but might be less effective without manually initiating gc.collect()
    • requires the ability to do partial/incremental collection. It might not be possible without significant rework in the micropython GC code
      • but should be far less work than supporting reference counting
      • and could potentially remain a compile time configuration
• minimize how often collection is required by avoiding new allocations
  • combined with manual control of collection timing, this can keep things as predictable as possible (although faster measurement certainly helps)
  • but at least for my use case, it's not practical to eliminate this entirely since using *args, **kwds in parameters or invocations usually creates temporaries that will have to be collected

[jbrelwof]

Perhaps the easiest quick improvement would be wrapping/mapping the C level gc_info(...) call for access in CircuitPython?

• a single call could provide the same information as calling gc.mem_alloc() and gc.mem_free()
  • calling gc_info(...) (in C) isn't cheap
  • both gc.mem_alloc() and gc.mem_free() internally call gc_info(...)
• anywhere you want to grab both values you're hit with the cost of calling gc_info twice
• this should be trivial to implement, add very little to the code size, and have zero impact on gc performance in general
• it would also provide a little more information than is available through gc.mem_alloc() and gc.mem_free()

[dhalbert]

In the latest alphas of 10.0.0, we've eliminated scanning for objets inside objects that contain no pointers (bytearrays, etc.). This speeds up many collections substantially. It's worth trying to see how it affects your particular program. See #10264.

[dhalbert]

You can also use gc.threshold() to invoke automatic gc earlier, when it will take less time.

[jbrelwof]

In the latest alphas of 10.0.0 ...

I'm currently running on 10.0.0-alpha.7-7-g363be5fe80 (2025-07-01). It did improve things significantly, but I still often get gc collection pauses in the hundreds of milliseconds. Many of the "collectables" are temporaries generated from things like list comprehensions and using (as parameters or in invocations) *args, **kwds. Also string formatting, but most of that can be eliminated easily enough.

I've put together a benchmark harness to help identify what causes temporary instances to be created and left for cleanup by the collector. I need to add more to it - for example I haven't actually tested list comprehensions or f"format {strings}", but *args, **kwds definitely add to the garbage heap.

[jbrelwof]

You can also use gc.threshold() to invoke automatic gc earlier, when it will take less time.

I don't think this would help in my use case, at least without implementing gc.freeze() or something similar. By the time everything is initialized, there are already a lot of objects in play, and even though they're effectively "immortal" gc.collect() still has to walk them every time. So gc,threshold() might improve the startup speed a bit, and it might even improve the "main loop" a little (as a side effect of potentially minimizing fragmentation and improving locality / keeping frequently used bits out of PSRAM / ...) but in my use case any call to gc.collect() after everything is "up and running" is still gonna hurt.

[jbrelwof]

You can also use gc.threshold() to invoke automatic gc earlier, when it will take less time.

I was going to give it a try, but unfortunately gc.threshold() doesn't appear to be available in the 10.0 alpha build I'm using.

dir(gc)=['__class__', '__name__', '__dict__', 'collect', 'disable', 'enable', 'isenabled', 'mem_alloc', 'mem_free']