[lfs-dev] Perl test times
bruce.dubbs at gmail.com
Fri Jun 30 15:44:16 PDT 2017
Jonathan Cottrill wrote:
> Bruce Dubbs wrote:
>> Jonathan Cottrill wrote:
>>> As mentioned in Chapter 6, the Perl tests take quite a bit of time when
>>> with "make -k test". The testing framework used by Perl doesn't respect
> the -j
>>> option to make, so the tests never run in parallel.
>>> There's another way to run the Perl test suite, using the test_harness
>>> target and the TEST_JOBS variable; for example:
>>> TEST_JOBS=8 make test_harness
>>> (I picked 8 in this case based on trial and error and load averages on my
>>> quad-core system.) On my system, the test time went from 10m6s to 2m24s.
>>> The docs (https://perldoc.perl.org/perlhack.html#Parallel-tests) do point
>>> a caveat that could make this less than ideal for LFS builders: There are
>>> tests that supposedly become flaky when run in parallel, like dist/IO/t/
>>> io_dir.t. However, I've run the suite several times this way, and have yet
>>> see any new failures (the expected Compress-Raw-Zlib and IO-Compress
>>> still occur, of course). dist/IO/t/io_dir.t is always reported as "ok".
>>> A slight oddity of running this way is that the output is a bit different.
>>> Skipped tests have additional information about why they're skipped, and
>>> final report on test failures is more detailed.
>> At about 2.5 SBU, I do not think the test time for perl is excessive. I
>> think we can just leave this as is.
>> I have added notes to libtool and autoconf on how to speed up tests.
> Makes sense to me. Thanks!
> I'm specifically working on improving build/test times for packages, now; if I
> find other things, is there a threshold in SBU where it's worth mentioning on
> this list? Don't want to spam people, but also happy to pass on my findings
> when they might be helpful.
Posting here is fine. It does get picked up and can be found with various
More information about the lfs-dev