В Sun, 13 Aug 2023 00:59:40 -0700 Michael Topper <miketopper...@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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
