Build time out of control

[msevestre]

@pchelle @abdullahhamadeh We need to check this. The max build time on appveyor is 1hour

2 months ago we were at 11 min

Then we updated some vignettes and more than doubled the time

The last addition a few days ago brought the build time to 45min!

Our examples in vignettes need to be contrived examples so that they run fast.
Can we identify the examples that are sucking the life out of our builds?

[abdullahhamadeh]

Would it make sense to simply include vignettes as pdfs?

[msevestre]

I don;t think so. Vignettes are generated based on the code and therefore need to be created with the latest version. This is the only was to ensure that they work as expected all the time. It will also break the build if they don't work, which is good.

Or we have to create a nightly version of the reporting engine => WE build all the time without vignettes and once a day with vignettes. Right now, the feedback loop is just too painful

But why is it so long? We agreed that we would used small pop and simplified model for the vignettes.

[msevestre]

This is with the latest changes

soon the build will fail because of a timeout. This is not ok

[pchelle]

There are 2 places where we can save a lot of time:

• vignettes
• tests in testthat

The problem is that for most of the test and examples from vignette we basically re-run almost all the workflows every time.
And this can be quite time consuming if there are simulations and sensitivity analyses.
For testthat, I think we can re-use results from a workflow folder to check other tests.
For vignettes, I would keep only one or two examples for which the simulation and SA results are already stored in test or extdata.
Thoughts ?

[msevestre]

That could work. But the results for the vignettes would have to be the one calculated previously. We should not save any data from local calculation otherwise we are in for a lot of pain. Whatever we use in the tests and SA should have been calculated with the current version of the code. So if you can store is somewhere temp and reuse it, great

Other alternative:
what about using a simulation with only two 3 compartments and a few parameters in each?
The workflow does not have to run a full PBPK model. We just need the minimal complexity

In ospsuite-r, we have the following simple model
https://github.com/Open-Systems-Pharmacology/OSPSuite-R/blob/develop/tests/data/simple.pkml

[pchelle]

I think both should be implemented as much as possible (i.e. simple models instead of full models such as Ralegravir.pkml and temp folders where results are reused).
Is it okay to do that before the release or should we wait a bit ?

[msevestre]

Let's wait unless we start to hvae build failings due to timeout before we introduce temo folders.

However, not using a model such as Ralegravir which is massive should be done now (20MB FILE!!)