Problem/Motivation
In
📌
Reduce CPU requirement and concurrency for unit tests
Needs review
we're able to reduce both CPU and concurrency while maintaining similar test run duration speed for unit tests. However this also made me realise it's possible to optimize the spinlock protection in run-tests.sh
Most of our tests take around 300ms to run, so it's entirely possible that every time we add a test, another test has already finished in the meantime - i.e. with 8 tests at a time taking 300ms each, a test will finish on average every <40 ms.
Let's say we have 800 test classes and 8 concurrency, this means even if all tests started and finished at exactly the same time, we'd have to add 8 tests 100 times. With a 200ms usleep() call, that would be 20 seconds spent in usleep(). But since not all tests start and finish in the same time, we probably sleep more than that.
Steps to reproduce
Proposed resolution
We can assume that adding a new child process takes enough time that we don't need to sleep - and only sleep when no spare child processes are available. That will still avoid a spinlock, but it will avoid unnecessarily sleeping.
I think the 200ms usleep() itself is probably about right though, because if multiple tests finish within the 200ms we then add multiple new tests.
This is unlikely to have any effect on functional or functional js tests, but it might be a small benefit for unit and kernel tests where we run more classes in a single job.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet