@dc42
I have also wondered about how many moves need to be processed each time. My Apritner firmware does not optimize unnecessary computations, it does a full planning round when it decides to recalculate. When I tried to optimize this (by going back only as far as something changes), I found that it took more cycles on average, so I didn't go with it. Though, this was probably after I implemented this bunching so it doesn't exactly contradict what you're saying.
On the other hand, I'm pretty sure that it's easy to hit the worst case with the right input. I think that generally this is any input where you are constantly "out of lookahead", i.e. the speed is artificially limited because the buffer is too small given the desired speed and the max acceleration. I believe you would get into a situation where all planned moves are decelerating, and you are repeatedly turning the first move into a constant-speed one while increasing the speeds in all the other moves. This situation is easier to achieve when you have a non-cartasian coordinate system, and the firmware handles this by splitting up the move into small pieces (I know dc42-firmware does not do it this way).
I have also wondered about how many moves need to be processed each time. My Apritner firmware does not optimize unnecessary computations, it does a full planning round when it decides to recalculate. When I tried to optimize this (by going back only as far as something changes), I found that it took more cycles on average, so I didn't go with it. Though, this was probably after I implemented this bunching so it doesn't exactly contradict what you're saying.
On the other hand, I'm pretty sure that it's easy to hit the worst case with the right input. I think that generally this is any input where you are constantly "out of lookahead", i.e. the speed is artificially limited because the buffer is too small given the desired speed and the max acceleration. I believe you would get into a situation where all planned moves are decelerating, and you are repeatedly turning the first move into a constant-speed one while increasing the speeds in all the other moves. This situation is easier to achieve when you have a non-cartasian coordinate system, and the firmware handles this by splitting up the move into small pieces (I know dc42-firmware does not do it this way).