Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[mainloop-] wait less time between quick replay commands #2635 #2635

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

midichef
Copy link
Contributor

@midichef midichef commented Dec 15, 2024

Addresses #2634.

The problem is new to v3.1. It came from my patch 02432ff, which fixed slowness during replay of long CPU-heavy commands (#2369). Screen redraws happened too frequently, taking CPU time away from command execution. The fix introduced a delay of 0.1 seconds (nonidle_timeout) between screen redraws, as intended. But unfortunately, the delay also happens between each command. That slows down files that contain many replay commands. For example, a reply file (sheets.vdj in #2364) with 14 lines runs 1.5 seconds slower than it did in v3.0.

This PR gets rid of the 0.1 s wait for commands when no background thread is ongoing. The intention is to slow down redraws/replays only after running a threaded command that may run for a long time, like open-file. The change fixes most of the delay in replay, though it does not bring back the full speed of v3.0.

For the example file sheets.vdj, the slowness compared to v3.0 shrinks from +1.5 s to +0.6 s. The remaining +0.6 s occurs because there are 4 commands that create a 0.1 s delay: open-file and each of the three pivot commands. Each of those creates a new sheet, and each new sheet makes a background thread for reload(). Each background thread creates a 0.1s delay during replay.

Overall, the bugs #2369 and #2634 come from the structure of mainloop(): every time through the loop, it draws the screen and replays a command, and then waits out the delay. To get the speed back to the level of v3.0, we need the loop to use different delays for replay vs. redraw, simultaneously. So during replay, vd could run the mainloop more often than now, but not draw the screen every time through the loop, and not replay a command every time through. But implementing that change is too complex for me to tackle.

Copy link
Owner

@saulpw saulpw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This loop is tricky. We want to show every step in the replay, which requires at least a redraw (use -b -i to not see every step). But I agree, even with this requirement, the delays after showing add up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants