[issue30498] Run Python's slowest tests in the first 3/4 of tests when using -r

2017-06-03 Thread Brett Cannon
Brett Cannon added the comment: Travis takes nearly 22 minutes to do a test run with the slowest test currently at just under 8 minutes. That means on Travis the slowest test takes roughly 1/3 of the time. But with your machine taking literally 2 minutes, or 1/10 the time as Travis, to do a

[issue30498] Run Python's slowest tests in the first 3/4 of tests when using -r

2017-06-03 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: See also issue30417. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue30498] Run Python's slowest tests in the first 3/4 of tests when using -r

2017-06-02 Thread Terry J. Reedy
Terry J. Reedy added the comment: Starting longer running tests sooner only make sense if one runs them in parallel with -jn. I just tried installed 64 bit 3.6.1 with -r -j12 (forgot -ugui). Total duration: 108 seconds. The last to finish was test_multiprocessing_spawn after 84 seconds, 5

[issue30498] Run Python's slowest tests in the first 3/4 of tests when using -r

2017-05-28 Thread Brett Cannon
Brett Cannon added the comment: One way to control this would allow `-r` to take an optional `fast` argument to do this selective shuffle of the slowest tests, i.e. `-r fast` would still randomize but control for the slowest tests showing up in the first 75% of tests. --

[issue30498] Run Python's slowest tests in the first 3/4 of tests when using -r

2017-05-28 Thread Brett Cannon
New submission from Brett Cannon: If we guaranteed that the slowest tests in the test suite started early enough in the test run to complete before the final test finished, we could shave off several minutes worth of time in cases where the slowest tests are the hold-up. So perhaps if we