I’m not sure what tools you used to benchmark the code. Be aware that some tools modify the code to gather usage statistics, and these tools can dramatically alter the relative performance of the programs themselves. They can therefore provide misleading results. I typically measure performance using the LInux perf tool to avoid those issues. I’m surprised the C code was so much higher than the Python code - though I’m not surprised that the itersolve and step compression code are heavy consumers of CPU time.
Yeah - the itersolve system currently resets its predictions at the start of every gcode move. It’s difficult to make predictions across moves though because we expect each gcode move to change the pattern of steps. (Putting aside extreme cases like over-specified arcs, the purpose of each new gcode move is to alter the pattern of toolhead movement…)
Cheers,
-Kevin