On Sat, 7 May 2022, Zebediah Figura (she/her) wrote: [...]
There's also all the timing issues in sound, locking (timeout aspects) and timer tests.
Hmm, I guess that means we should let anything that calls timeBeginPeriod() run by itself. In practice that only seems to be winmm:timer and mmdevapi:spatialaudio? Maybe you're referring to something else I'm missing?
mmdevapi:capture and mmdevapi:render have timing issues too. But there are also a number of places where we wait for something for a short time and may get a timeout due to the system being busy.
[...]
Hmm. Of the eight tests mentioned there, two are related to installers, and four are related to... hitting the internet data cap?
The data cap is typically 10 GB and I set it when I'm done configuring the VM. So the tests shouldn't hit the cap.
[...]
By number of test units, I think there's a lot that can be parallelized. That might not translate to time, though. Unfortunately the longest-running tests fall mostly in the exceptions listed above (msi, d3d, user32...), so maybe it won't help much.
Based on somewhat old data, we have about 700 test units, 160 of which take more than 1 second, 110 of which take more than 2 seconds, 70 of which take more than 5 seconds, 45 of which take more than 10 seconds, 30 of which take more than 20 seconds, 10 of which take more than 50 seconds.
The repartition probably did not change too much.