This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
t/harness: Add option for faster test suite execution
authorKarl Williamson <khw@cpan.org>
Sun, 12 Apr 2020 21:13:25 +0000 (15:13 -0600)
committerKarl Williamson <khw@cpan.org>
Wed, 2 Dec 2020 21:32:13 +0000 (14:32 -0700)
commit9cbb5ac7dcf644c817e4072abb4f08e1eb92ae0c
tree3405c1a55f7be7b6411455d7fe14fb0a689f15f9
parentf0ba45bd255e8eb18fb9ac59aa032cc44a0b8633
t/harness: Add option for faster test suite execution

This commit adds an environment variable, PERL_TEST_HARNESS_ASAP, which
if set to non-zero increases the parallelism in the execution of the
test suite, speeding it up on systems with multiple cores.

Normally, there are two main test sections, one for core and the second
for non-core tests, and the testing of the non-core one doesn't begin
until the core tests are complete.  Within each section, there are a
number of test categories, like 're' for regular expressions, and
'JSON::PP' for the pure perl implementation of JSON.

Within each category, there are various single .t test files.  Some
categories can have those be tested in parallel; some require them to be
done in a particular order, say because an earlier .t does setup for
subsequent ones.  We already have this capability.

Completion of all the tests in a category is not needed before those of
another category can be started.  This is how it already works.

However, the core section categories are ordered so that they begin in a
logical order for someone trying to get perl to work.  First to start
are the basic sanity tests, then by roughly decreasing order of
widespread use in perl programs in the wild, with the final two
categories, porting and perf, being mainly of use to perl5 porters.
These two categories aren't started until all the tests in the earlier
categories are started.  We have some long running tests in those two
categories, and generally they delay the start of the entire second
section.

If those long running tests could be started sooner, shorter tests in
the first section could be run in parallel with them, increasing the
average CPU utilization, and the second section could begin (and hence
end) earlier, shortening the total elapsed execution time of the entire
suite.

The second section has some very long running tests.  JSON-PP is one of
them.  If it could run in parallel with tests from the first section,
that would also speed up the completion of the suite.

The environment variable added by this commit does both things.  The
basic sanity test categories in the first section continue to be started
before anything else.  But then all other tests are run in decreasing
order of elapsed time they take to run, removing the boundaries between
some categories, and between the two sections.

The gain from this increases as the number of jobs run in parallel does;
slower high core platforms have the highest increase.  On the old
dromedary with 24 cores, the gain is 20%, almost 2 minutes.  On my more
modern box with 12 cores, it is 8%.
t/harness