Closed Puzzled-Face closed 5 months ago
Most likely due to the dose grid in DefaultDADesign()
:
emptydata <- DataDA(
doseGrid = c(0.1, 0.5, 1, 1.5, 3, 6, seq(from = 10, to = 80, by = 2)),
Tmax = 60
)
Hmmm. changing the dose grid to
doseGrid = c(0.1, 0.5, 1, 1.5, 3, 6, seq(from = 10, to = 80, by = 10))
reduces the execution time to 55 seconds. So that appears not to be the issue.
@danielinteractive I think a potential solution would be to mock .DefaultDASimulations()
during tests so that rather than creating a new instance every time the default constructor is called, we simply load the data from disk. Reading the Rds
file should be effectively instant, so that close to a minute would be saved every time the default constructor is called.
To do this.
testdata
folder under tests/testthat
.DefaultDASimulations()
interactively and save the object to an Rds
file in testdata
helper-mocks.R in
tests/testthat`helper-mocks.R
create the function belowsource
helper-mocks.R
at the start of every test file that calls .DefaultDASimulations()
The mocked function would be
local_mocked_bindings(
.DefaultDASimulations = function(...){
readRDS(testthat::test_path("testdata", "DefaultDASimulations.Rds")
}
)
or similar.
The major advantage of this approach would be that there are no changes necessary to any package code and all test results would remain unchanged.
See here for more details on mocking tools.
.DefaultDASimulations
is not called explicitly in any test. It is (probably) called implicitly by tests in
test-CrmPackClass-class.R
test-CrmPack-class-methods.R
test-helpers.R
test-helpers_knitr.R
We could even modify .DefaultDASimulations()
itself to load a static .Rds
file as well.
This could be created by usethis::use_data(internal = TRUE)
. See section 7.2 of this for more information.
Yeah good idea, I think this kind of caching makes sense
.DefaultDASimulations()
has a relatively long execution time. Can this be improved?The same is true, to a lesser extent, of
DefaultSimulations()
.