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?
[SOLVED]how to breakup garbage collection (gc.c)
[SOLVED]how to breakup garbage collection (gc.c)
Last edited by jickster on Wed Nov 01, 2017 5:56 pm, edited 1 time in total.
Re: how to breakup garbage collection (gc.c)
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.with nothing to actually collect
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.
Re: how to breakup garbage collection (gc.c)
I get there's not a way around it.stijn wrote: ↑Fri Oct 27, 2017 1:54 pmAre 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.with nothing to actually collect
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 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
Re: how to breakup garbage collection (gc.c)
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?