[R-pkg-devel] Unexpected multi-core CPU usage in package tests

[Jon Clayden]

Dear all,

I'm slightly going out of my mind trying to resolve a CRAN rejection
based on the note

    Flavor: r-devel-linux-x86_64-debian-gcc
    Check: tests, Result: NOTE
        Running 'tinytest.R' [20s/5s]
      Running R code in 'tinytest.R' had CPU time 4.4 times elapsed time

This applies to package 'tractor.base', which contains no compiled
code and is not parallelised, but has (first-party) package 'mmand' as
a dependency, which uses OpenMP where available.

Further investigation suggests that skipping the tests that use that
package doesn't resolve the issue, and indeed it seems to occur in
another dependency, 'RNifti', which doesn't use OpenMP, and has no
hard dependencies of its own except 'Rcpp'.

My testing route is to install the packages within the
'rocker/r-devel' Docker container, which is Debian-based, then use
'time' to evaluate CPU usage. Note that, even though 'RNifti' does not
use OpenMP, setting OMP_NUM_THREADS changes its CPU usage:

    # /usr/bin/time Rscript -e "library(RNifti);
testthat::test_dir('tests/testthat')"
    ...
    5.46user 4.88system 0:04.06elapsed 254%CPU (0avgtext+0avgdata
387244maxresident)k
    0inputs+8032outputs (208major+97868minor)pagefaults 0swaps

    # /usr/bin/time env OMP_NUM_THREADS=1 Rscript -e "library(RNifti);
testthat::test_dir('tests/testthat')"
    ...
    3.54user 0.13system 0:03.67elapsed 100%CPU (0avgtext+0avgdata
382060maxresident)k
    0inputs+8032outputs (222major+98893minor)pagefaults 0swaps

I see similar results for packages using 'tinytest' as well as
'testthat'. I am not requesting parallelised testing from either
framework.

So, my questions are

(i) is there something wrong with this evaluation that's leading me astray?
(ii) what might the source of this unexpected parallelism be?
(iii) how can I reliably meet CRAN's requirement not to use too many
CPU cores, other than setting OMP_NUM_THREADS before starting R, which
I can't control?

Thanks in advance.

All the best,
Jon