Add functionality to record processing time of the whole script or individual parts of the script

[Jo-Schie]

Besides good code documentation, open data, and information on the system, reproducibility might also depend on processing capacities of the machine of a researcher. I would suggest that there is an option that shows how long the execution of file-rendering takes for a given workflow and possibly also the processing time of individual code-chunks in order to be able to assess which code blocks takes up most processing time.

A workaround for this, of course, is to just collect starttime<-Sys.time() and stoptime<-Sys.time() at the beginning and end of a script, but since this package tries to create a standard for documentation (which is awesome) it could be n good if this information was collected in standard workflowr applications. Also, it might be nice to get information on the hardware (number cpus, available RAM) with which the script was rendered...not sure, however, if this was not too privacy-sensitive.

[pcarbo]

@Jo-Schie I think this is a great suggestion. Would you be willing to prototype an implementation of your idea, and submit a pull request?

[Jo-Schie]

Hi @pcarbo . I'm not an experienced software developer, so I would not really know how to implement this. Happy to contribute though in any other way possible (e.g. testing with larger datasets or similar).

[lianos]

For what it's worth, there is an example of how to configure an Rmd document so that it clocks the runtime of each chunk in the R Markdown Cookbook (13.3 Report how much time each chunk takes to run).

There are examples that show you how to (1) simply print the runtime after each cunk is run; or (2) store the runtimes in a global list and do what you want with it after.

[jdblischak]

@Jo-Schie Thanks for starting this discussion! I agree this is useful information, and I've considered ideas like this before (i.e. report various metrics per chunk). My main concerns at the moment are 1) implementing this correctly (e.g. make it robust, and allow users to disable it if they don't like it), and 2) I try to keep workflowr content to a minimum to avoid distracting from the main analysis in the file, and a workflowr button per chunk seems excessive.

In an ideal world, I would create a general mechanism that would allow users to run arbitrary checks per chunk. This would allow features like this issue and also the proposal in #242 to be chosen piecemeal by the user. Unfortunately I don't have the free time available at the moment to implement this. My main focus right now is to fix existing features that are broken (or may be broken in the future, e.g. by updates that GitHub makes regarding authentication).

(number cpus, available RAM)

Reporting this type of hardware information would be tough to do well, especially cross-platform, which is likely why the R developers don't include it in sessionInfo(). You can get the cores with parallel::detectCores(), but I've had trouble with that function on HPC clusters (e.g. it will report all the cores on the compute node, even if you only requested a few cores to be available for the job). I'm not familiar with a way to detect the available RAM, but a quick search finds this SO thread confirming my suspicion that it would be hard to do cross-platform.

For what it's worth, there is an example of how to configure an Rmd document so that it clocks the runtime of each chunk in the R Markdown Cookbook (13.3 Report how much time each chunk takes to run).

Thanks @lianos! It's worth a lot to me :-) I knew I had seen an example like this before, and you saved me the time trying to track it down.