TOOLS/command-test.lua: add test for async subprocess command blocking#17670
TOOLS/command-test.lua: add test for async subprocess command blocking#17670llyyr wants to merge 2 commits intompv-player:masterfrom
Conversation
llyyr
force-pushed
the
add-rapid-dispatch-command-test
branch
from
a23d070 to
4520121
Compare
TOOLS/lua/command-test.lua
Outdated
| function() end) | ||
| end | ||
| print(string.format("done rapid subprocess dispatch in %.3fms", | ||
| (mp.get_time() - rapid_start) * 1000)) |
There was a problem hiding this comment.
This is good test to test "raw" throughput of spawning things.
I also had in mind to see how it affects main thread. The simple way, would be to spawn processes, that takes long time to finish and ensure that main thread still can process commands and what is the difference compared when no sub-processes are made.
But I'm not sure myself how well or if at all it's possible to test in lua with commands system. But at least while command_native_async is running, we should still be able to process command and without delay.
Food for thought, I don't have direct suggestion how to do the testing.
There was a problem hiding this comment.
This is good test to test "raw" throughput of spawning things.
It tests the throughput of the speed of async subprocess command processing, plus the time mpv is suspended due to fork etc. An async command simply queues the task for running in the future. Spawning speed can be much slower.
On Windows, where process spawning is slow, this test completes in 3 ms for me, much faster than on Linux, because process creation on Windows does not block the main thread.
There was a problem hiding this comment.
I tried to add a test like this in the second commit.
The simple way, would be to spawn processes, that takes long time to finish
I wasn't sure if you meant to spawn processes that take a long time to dispatch (test 1), or actually live for a long time (something like sleep 10). I assumed you meant the former, but it can easily be modified for the latter.
There was a problem hiding this comment.
On Windows, where process spawning is slow, this test completes in 3 ms for me, much faster than on Linux, because process creation on Windows does not block the main thread.
There's a chance you used the version of the test where it wasn't printing from the callback of command_native_async. If so please retest. The current version is correct
There was a problem hiding this comment.
My main point for this benchmark idea was to capture the issue with crackling audio without crackling audio test, if you know what I mean.
There was a problem hiding this comment.
Then I think the current responsiveness test achieves that. But 5ms is quite big for things like audio buffers
There was a problem hiding this comment.
There's a chance you used the version of the test where it wasn't printing from the callback of command_native_async. If so please retest. The current version is correct
I tested the new version on Windows. Rapid process dispatch now takes 1.7 s, and responsiveness while spawning subprocesses is 0.005 ms. So as expected responsiveness is not an issue despite slow process spawning.
llyyr
force-pushed
the
add-rapid-dispatch-command-test
branch
from
4520121 to
f75d478
Compare
On master, this takes around 4000ms for me. While with mpv-player#14973 it completes in 10ms
This test measures how long commands take to run while the main thread is being hammered with async commands. I get the following result: [command_test] responsiveness baseline: 0.235ms [command_test] responsiveness while spawning subprocesses: 5.226ms
llyyr
force-pushed
the
add-rapid-dispatch-command-test
branch
from
deb8b17 to
06c3d90
Compare
3 participants
On master, this takes around 4000ms for me. While with #14973 it completes in 10ms