Shuffle LinearAlgebra tests to the front of the test queue #34456
Conversation
|
Sorry that this test dominates the CI time (I wrote this)... It is a super brute force test but it's really useful for catching bugs. FYI, you can reduce this number to make it shorter, but at the cost of the bug to be discovered much later than the actual PR touching the relevant code julia/stdlib/LinearAlgebra/test/addmul.jl Lines 122 to 123 in 159de94 |
|
It's not just addmul, some of the others also take a bunch of time. |
|
Ah, OK. I mixed it with JuliaLang/LinearAlgebra.jl#690. |
|
I mean, they're related, but if this works (maybe while simultaneously bumping the number of cores allotted to testing to make sure that all the LinearAlgebra tests start at one, then the other one is less urgent. |
|
Looks like there are ambiguities in Furlongs.jl that are test-order-dependent (only errors if Furlongs is loaded before the ambiguity tests). I'll try to fix them. |
|
This made the aarch64 bot 10 minutes faster. I think it's worth doing once the ambiguity error is fixed. |
|
This can be rebased and merged now. |
JeffBezanson
force-pushed
the
kf/linalgcifirst
branch
from
4df11b8 to
b6a944a
Compare
They take much longer than the rest of the tests, so if they're run at the end, they often determine the length of the entire test run. Instead, try running them at the start while there's still plenty of work to be done. Hopefully this will reduce overall duration of CI tests. If this doesn't work out as planned, we can try a more fine grained strategy to load balancing (e.g. by checking in a table of approximate runtimes and sorting according to that).
|
Could this be rebased to see whether it resolves the time-outs we see frequently? |
|
We used to do this, but I guess we lost it in the stdlib shakeup. |
…#34456) They take much longer than the rest of the tests, so if they're run at the end, they often determine the length of the entire test run. Instead, try running them at the start while there's still plenty of work to be done. Hopefully this will reduce overall duration of CI tests. If this doesn't work out as planned, we can try a more fine grained strategy to load balancing (e.g. by checking in a table of approximate runtimes and sorting according to that).
They take much longer than the rest of the tests, so if they're run at the end, they often determine the length of the entire test run. Instead, try running them at the start while there's still plenty of work to be done. Hopefully this will reduce overall duration of CI tests. If this doesn't work out as planned, we can try a more fine grained strategy to load balancing (e.g. by checking in a table of approximate runtimes and sorting according to that).
They take much longer than the rest of the tests, so if they're
run at the end, they often determine the length of the entire test
run. Instead, try running them at the start while there's still
plenty of work to be done. Hopefully this will reduce overall duration
of CI tests. If this doesn't work out as planned, we can try a more
fine grained strategy to load balancing (e.g. by checking in a table
of approximate runtimes and sorting according to that).