You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been using covr + testthat + travis for continuous integration checks on our gcamdata project. This set up had been working great although recently the time taken to run covr in particular had gotten unbearable enough that we decided to look into it. Long story short if we revert back to some older version of covr (2.2.2 / adffd69) we see runtimes more inline with what we would expect; using the latest version (3.0.0.9000 / 4e6da57) takes one order of magnitude longer:
Unfortunately I don't have much more insight than this as to what is going on. I have tried deleting all but the most minimal of tests and / or adding exclusions for the bulk of the code but in all cases the length of time to run the coverage tests are an order of magnitude longer than when running the full test using v2.2.2.
For the time being we will be reverting to using v2.2.2 but think it would still be a good idea to get to the bottom of this. Let me know if there is any more info I can provide to help diagnose what is going on.
The text was updated successfully, but these errors were encountered:
I can confirm the performance regression. It has to due with how R stores the parseData for packages, which covr uses for creating source references for conditionals withthout curly braces.
We have been using covr + testthat + travis for continuous integration checks on our gcamdata project. This set up had been working great although recently the time taken to run covr in particular had gotten unbearable enough that we decided to look into it. Long story short if we revert back to some older version of covr (2.2.2 / adffd69) we see runtimes more inline with what we would expect; using the latest version (3.0.0.9000 / 4e6da57) takes one order of magnitude longer:
Unfortunately I don't have much more insight than this as to what is going on. I have tried deleting all but the most minimal of tests and / or adding exclusions for the bulk of the code but in all cases the length of time to run the coverage tests are an order of magnitude longer than when running the full test using v2.2.2.
For the time being we will be reverting to using v2.2.2 but think it would still be a good idea to get to the bottom of this. Let me know if there is any more info I can provide to help diagnose what is going on.
The text was updated successfully, but these errors were encountered: