[R-pkg-devel] Examples are too long in computation for CRAN
Ivan Krylov
kry|ov@r00t @end|ng |rom gm@||@com
Sun Aug 13 10:42:59 CEST 2023
В Sun, 13 Aug 2023 00:59:40 -0700
Michael Topper <miketopper123 using gmail.com> пишет:
> - Setting the nthreads argument to 2 in fixest::feels() in case
> this is the problem as suggested.
Any chance you could be hitting some other code paths in the fixest
package while working on the objects returned by fixest::feols()?
Try running trace(fixest::getFixest_nthreads) and then running examples
in the same R session. Assuming that (1) your only problem is fixest
and (2) every fixest function that uses OpenMP consults
getFixest_nthreads() by default, it should be possible to catch them
this way.
If you see a call but aren't sure about its origin, try tracer =
quote(traceback()) or tracer = quote(browser()). (As a precaution,
untrace() the function before trace()ing it again.)
FWIW, modelsummary depends on both fixest and data.table, but it
doesn't look like you're creating threads via these.
> - Tried to use skip_cran_test() on the tests that include fixest
> regressions
For tests, there's one more option: fixest::setFixest_nthreads(1) at
the beginning of the file. This should eliminate any extra threads
originating from fixest. If you do this and the problem persists, it
must be something else. Unfortunately, this is global state, and using
this in examples will involve saving the previous value and then
restoring it later.
(If you had separate test files in tests/*.R, R would be able to tell
you which one causes excessive CPU time. Unfortunately, testthat idioms
and core R idioms don't work well together.)
It really is unfortunate that you cannot reproduce this without a
computer with a lot of cores and working OpenMP.
--
Best regards,
Ivan
More information about the R-package-devel
mailing list