[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 test run, Terry, I'm not worried about speeding up your 
machine. ;)

But yes, we could change it to being the first 50% if people wanted. The 75% 
was somewhat arbitrarily selected to not artificially constrain the introduced 
pseudo-randomness of the test order.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 seconds after the 2nd last.  So 
it started at 24 seconds, when about 150 of 405 tests had finished.  To not be 
a blocker, it needed to start at about 19 seconds, when 120 tests had finished.

I re-ran with 32 bit repository debug build and was not so lucky.  Test 404 
finished at 3:24.  Test_multiprocessing_spawn finished 1:33 later at 4:57, 
after 121 seconds.  It started at 2:57, when about 352 of 405 had finished.  
Test 303 (3/4the) finished at 2:41, 16 seconds earlier.

Conclusion: the 3/4 restriction will help, but is insufficient to really 
balance process loads.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 randomly inserted the 10 slowest tests in the first 3/4 of the 
complete test list we could make sure they finish early enough?

--
components: Tests
messages: 294658
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Run Python's slowest tests in the first 3/4 of tests when using -r
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com