According to my small tests: Tune TIMER_MIN_TRY_TICKS
It is slow 
There are 2 patches actually, one is a small optimization that can decrease load with chain updates, like a progress bar updates (update pixels only up to and including the changed one).
The second is the above hack.
Anyway, to test it out, there is: Testing Klipper Pull Requests
Or, probably shortcut git fetch --all, git checkout d2d8f0a or git cherry-pick d2d8f0a
Because this is an MCU side change, this requires reflashing the MCU afterwards.
The question is, would it allow us to update the pixels significantly further than the current master?
So, in a perfect scenario, there are 2 tests, one before and one after the patch.
Thanks!
PR is the Pull Request, generally read it as “Suggested changes”. If it is merged, they are accepted. If it is in any other state, they are in this “purgatory”.
As they are visible under klipper github repository, they are “suggested changes” to this repository.
I would even say, that generally, I would suggest to think about PRs in a way “Hey, look what I made, maybe you can find this useful!” - so suggestion/proposed changes for reason “X”.