Hello. I have a RStan-dependent package that I developed before rstantools was introduced, which I’ve finally gotten around to refactoring following the guidelines. I really like having the models precompiled and ready to go at runtime; it feels much more user-friendly (even though the principal user at this point is me).
However, there is one thing I’m finding increasingly onerous. The package contains an ever-growing number of Stan models, and typically I’m only working on one or two at a time. In the pre-rstantools version, that workflow involved modifying Stan and/or R code, rebuilding the package (using the Install and Restart button in RStudio), and testing the edited model(s) which would have to be recompiled when called. Now, per the step-by-step instructions, I do the following:
devtools::install(quick = FALSE)
This causes all the models to be recompiled regardless of whether they were edited, which takes an annoyingly long time. I know I can use
quick = TRUE to update only the R code or documentation, but is there a way to recompile only the Stan models that have changed since the last installation, or only specified models?
I don’t know if it matters, but I’m using rstantools 18.104.22.16800.
Thanks in advance!
I don’t use Rstudio, so I don’t know if there are known tricks that could help you with that.
I can offer two suggestions that you may cut down your compilation times:
If you are on Linux, I suggest to add
Sys.setenv(MAKEFLAGS="-j4") to your
~/.Rprofile file (something similar may work on Windows too, but you’ll have to do some research to find where this should be written. This means that compilation will use multiple cores (change that 4 to the number of cores you want to use).
This is more of a gimmick: I suppose that if you are working on a specific model and don’t want to recompile the rest, you could move the other stan files out of the
inst directory. As long as when you are not trying to run those other models, all should work fine.
But maybe @bgoodri or @jonah have a better solution at hand!
Thanks @mcol. I’m on Windows. I thought that I already had compilation set to use multiple cores, but
Sys.getenv('MAKEFLAGS') returns nothing and it’s not in my
Makevars.win either (would it work if inserted there? I’m not sure). So I’ll try that suggestion.
I had thought of #2, but was hoping there was a less kludgy solution. I suppose it’s not that much of a hassle, but still curious how others handle this scenario – I assume it must come up a lot.
The fact that
Sys.getenv('MAKEFLAGS') returns nothing only means that that environmental variable has not been set (which is the default). You should try
Sys.setenv(MAKEFLAGS='-j4') first, and see if that affects the compilation.
If you have a
Makevars.win you could add
CXXFLAGS += -j4 to it (I suppose that variable will work), but bear in mind that it may not be acceptable for CRAN if you care about that.