CRAN incoming checks: CPU time XX times elapsed time

Package development
,
1

Dear Posit Package dev hive mind,

I am one of the maintainers for APCalign.

I'm currently preparing a resubmission to fix a few bugs that threatens the removal of our package.

Despite passing R CMD CHECK --as-cran locally, and on rhub on CRAN-like runners, I keep tripping
with an incoming check with Debian (log).

Flavor: r-devel-linux-x86_64-debian-gcc
Check: tests, Result: NOTE
Running 'testthat.R' [937s/57s]
Running R code in 'testthat.R' had CPU time 16.5 times elapsed time

This is intriguing for a few reasons:

  1. There is no parallel processing in our package code
  2. I cannot replicate this elsewhere
  3. It seems to be only on Debian

I found Dirk Eddelbuettel's very thorough solution to managing code that uses more than one CPU on CRAN however, I am hesitant in implementing this because of the reasons above.

Would an R-package-fairy-god-mother have any kind words of advice to reproduce the note and show me a trick or two to manage it please?

Confused and grateful,

Fonti

1 Like
2

From a quick search, multiple discussions recommended setting Sys.setenv("OMP_THREAD_LIMIT" = 2). What happens if you add that to testthat.R?

Sources:

Also, cross-referencing your GitHub Issue CPU handling on CRAN · Issue #253 · traitecoevo/APCalign · GitHub

1 Like
3

Thanks so much @jdblischak, I must brush up my searching skills.
Adding Sys.setenv("OMP_THREAD_LIMIT" = 2). to my testthat.R file enabled the package to pass all the CRAN tests and incoming checks.

Its now on its way to CRAN! :tada:

I've always been so dissuaded to edit testthat.Rbut this is a great example of when to make an exception!

1 Like
4

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.