knitr::opts_chunk$set( collapse = TRUE, comment = "#>", fig.path = "man/figures/README-", out.width = "100%" )
Website: https://rmflight.github.io/importedPackageTimings
The goal of importedPackageTimings
is to help R package developers determine if any of the
R packages their package depends on (i.e. imports
) make loading their own package slow.
To accompmlish this, it uses independent R sessions from the future
package
to time how long it takes to load each of the packages listed in the Imports
and Depends
fields of the package in question. Although it will take a long
time because it only uses a single core at a time (the only way I could get
reliable timings), the times seem to be reliable.
Currently, importedPackageTimings
only exists on Github, so install it with:
remotes::install_github("rmflight/importedPackageTimings")
Warning: This package has only been tested on Linux
, using the future
and the multiprocess
backend. I think this should work on Mac
without any
issues. I'm not sure which backend should be used on Windows
such that each
call to furrr::future_map_dbl
is launching a new R sub-process that will be
completely clean.
The way to know if the code is working correctly is to look at the consistency
of the timings
returned from imported_timings
for a sufficiently long
imported package. They should be very consistent. If the process is not new,
then the first timing will be long, and subsequent ones much, much shorter.
For example, lets look at a Bioconductor package I've seen take a long time to
load, xcms
.
# not run library(furrr) plan(multiprocess) library(importedPackageTimings) xcms_time = imported_timings("xcms")
The package provides two types of timings, the time required for the dependency
to load (type = pkg
), and then the time required for the package to load after
the dependency (type = after
).
data(xcms_time) knitr::kable(head(dplyr::select(xcms_time, -timings)))
We can use the pkg
entries to see which imports actually take a long time
to load, possibly contributing to the long load time of our package in question.
library(ggplot2) ggplot(dplyr::filter(xcms_time, type %in% "pkg"), aes(x = min / 1e9, y = package)) + geom_point()
From this plot, we can see that MSnbase
looks like it is taking the longest to
load outside of xcms
itself.
We can use the after
entries to see which imports after loading have the
smallest time to load our package in question, which also implies they may be the
culprit causing long load times.
ggplot(dplyr::filter(xcms_time, type %in% "after", which %in% "import"), aes(x = min / 1e9, y = package)) + geom_point()
Licensed under the MIT license, with no warranty.
Please note that the importedPackageTimings
project is released with a Contributor Code of Conduct. By contributing to this project, you agree to abide by its terms.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.