Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make styler faster #78

Closed
lorenzwalthert opened this issue Jul 19, 2017 · 2 comments
Closed

make styler faster #78

lorenzwalthert opened this issue Jul 19, 2017 · 2 comments

Comments

@lorenzwalthert
Copy link
Collaborator

lorenzwalthert commented Jul 19, 2017

The following could make styler run faster:

  • dropping unnecessary select() and arrange() statements.
  • early termination (e.g. rules?)
  • consider replacing some tidyverse calls with base R if substitution
    does not make the code "uggly"? What do you think @krlmlr ?
  • which statements related to needs_indention()
microbenchmark::microbenchmark(dplyr = dplyr::mutate(mtcars, driver = 3), 
                               baseR = mtcars$driver <- 3)
#> Unit: microseconds
#>   expr      min       lq      mean   median        uq        max neval cld
#>  dplyr 1969.341 2009.056 3740.7995 2037.379 2091.4205 152117.420   100   b
#>  baseR   11.663   13.735   24.1628   20.456   22.9275    433.822   100  a

microbenchmark::microbenchmark(dplyr = dplyr::slice(mtcars, 1:3), 
                               baseR = mtcars[1:3, ])
#> Unit: microseconds
#>   expr      min       lq      mean    median       uq      max neval cld
#>  dplyr 2094.290 2148.480 2446.0150 2191.8545 2271.761 8700.220   100   b
#>  baseR  138.072  155.203  176.9532  165.3705  189.216  431.295   100  a

# pipe does probably not slow down things much.
library(magrittr)
microbenchmark::microbenchmark(dplyr = mtcars %>% summary(), 
                               baseR = summary(mtcars))
#> Unit: milliseconds
#>   expr      min       lq     mean   median       uq      max neval cld
#>  dplyr 4.550347 4.619500 5.089398 4.695070 4.833018 9.004815   100   a
#>  baseR 4.390407 4.497096 4.924098 4.548395 4.833101 8.284952   100   a

These are just some thoughts, profiling of our code is probably a better place to start anyways...

@krlmlr
Copy link
Member

krlmlr commented Jul 19, 2017

Let's identify our bottlenecks first, you could try profvis.

@lorenzwalthert lorenzwalthert mentioned this issue Jul 25, 2017
@lorenzwalthert
Copy link
Collaborator Author

lorenzwalthert commented Jul 27, 2017

With #90, I think we can close this, at least for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants