[SOLVED]how to breakup garbage collection (gc.c)

[jickster]

I have a custom cooperative RTOS and gc.collect() with nothing to actually collect, no threads takes 533us which is way too much.

Which C-code of the gc.c - starting with gc_collect() - takes so long?

[stijn]

with nothing to actually collect

Are you sure? Standard MicroPython allocates one big chunk of memory at the start of execution and then continuously uses that. Once all memory in it has been used and/or fragmented there is a need for gc_collect. Only if you never reach that threshold there is nothing to collect. So in that case you could just skip calling gc_collect all together I guess.

Anyway as far as I know what takes long is iterating over heap pointers to see whether they are still in use. There's not really a way around it, I think.

[jickster]

with nothing to actually collect

Are you sure? Standard MicroPython allocates one big chunk of memory at the start of execution and then continuously uses that. Once all memory in it has been used and/or fragmented there is a need for gc_collect. Only if you never reach that threshold there is nothing to collect. So in that case you could just skip calling gc_collect all together I guess.

Anyway as far as I know what takes long is iterating over heap pointers to see whether they are still in use. There's not really a way around it, I think.

I get there's not a way around it.
I need to know where in the garbage collector code the time consuming parts are so that I can surround them with calls to yield to my RTOS so I can split up this time-consuming block to run in multiple time-slices

[stijn]

If you want to do that in an accurate way you'll have to measure it. There's nothing inherently time-consuming in gc.c (except possibly the calling of the finaliser since that calls arbitrary user code): operations like VERIFY_MARK_AND_PUSH are just load/comparisions/store. It's just that they get called many times. So I could tell you 'gc_sweep and gc_collect_root are time-consuming' but 1) I don't know if it really is, in your particular program 2) I could measure it but that would be on a pc and I don't know how representative that is for your case 3) I don't know how that would help you 4) I have the feeling that if you just start putting extra yields for an RTOS solely based on what people on the internet tell you, you're doing it wrong. I mean, I'd think this requires some careful considerations and understanding of what is going on, not merely assumptions. Now the code in gc.c isn't that complicated so it shouldn't take you that long to understand it. But then again, without actually measuring individual parts how are you ever going to know what really is worth splitting up?