An open API service indexing awesome lists of open source software.

https://github.com/rmflight/importedPackageTimings

Time combinations of loading packages
https://github.com/rmflight/importedPackageTimings

Last synced: over 1 year ago
JSON representation

Time combinations of loading packages

Awesome Lists containing this project

README

          

---
output: github_document
---

```{r setup, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>",
fig.path = "man/figures/README-",
out.width = "100%"
)
```
[![Travis build status](https://travis-ci.org/rmflight/importedPackageTimings.svg?branch=master)](https://travis-ci.org/rmflight/importedPackageTimings)
[![Coverage status](https://codecov.io/gh/rmflight/importedPackageTimings/branch/master/graph/badge.svg)](https://codecov.io/github/rmflight/importedPackageTimings?branch=master)

# importedPackageTimings

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.

## Installation

Currently, `importedPackageTimings` only exists on Github, so install it with:

```{r install, eval=FALSE}
remotes::install_github("rmflight/importedPackageTimings")
```

## Supported Platforms

**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.

## Example

For example, lets look at a Bioconductor package I've seen take a long time to
load, `xcms`.

```{r example, eval=FALSE}
# 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`).

```{r show_table, results = 'asis'}
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.

```{r show_pkg}
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.

```{r show_after}
ggplot(dplyr::filter(xcms_time, type %in% "after", which %in% "import"),
aes(x = min / 1e9, y = package)) +
geom_point()
```

## License

Licensed under the MIT license, with no warranty.

## Code of Conduct

Please note that the `importedPackageTimings` project is released with a [Contributor Code of Conduct](CODE_OF_CONDUCT.md). By contributing to this project, you agree to abide by its terms.