-
Notifications
You must be signed in to change notification settings - Fork 14
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
conflict_prefer()
is slow
#75
Comments
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Ok, if the actual data manipulation is no slower, then you shouldn't be benchmarking it. So the actual reprex is this: library(conflicted)
load_packages <- function() {
library(data.table, warn.conflicts = FALSE)
library(dplyr, warn.conflicts = FALSE)
library(lubridate, warn.conflicts = FALSE)
}
declare_conflicts <- function() {
conflicted::conflict_prefer("shift",winner = "data.table",quiet = T)
conflicted::conflict_prefer("last",winner = "dplyr",quiet = T)
conflicted::conflict_prefer("first",winner = "data.table",quiet = T)
conflicted::conflict_prefer("year",winner = "lubridate",quiet = T)
conflicted::conflict_prefer("month",winner = "lubridate",quiet = T)
conflicted::conflict_prefer("day",winner = "lubridate",quiet = T)
}
bench::mark(
load_packages(),
declare_conflicts(),
check = FALSE
)
#> Warning: Some expressions had a GC in every iteration; so filtering is disabled.
#> # A tibble: 2 × 6
#> expression min median `itr/sec` mem_alloc `gc/sec`
#> <bch:expr> <bch:tm> <bch:tm> <dbl> <bch:byt> <dbl>
#> 1 load_packages() 35.4ms 36.7ms 27.2 21MB 25.2
#> 2 declare_conflicts() 67.6ms 71.3ms 13.9 10.1MB 23.9 Created on 2022-10-31 with reprex v2.0.2 Does that accurately capture the performance issue you are experiencing? |
Yes indeed, that's a better reprex Hadley. 👍🏼
And now we can see the
I get the following:
Although 1.17 second is not bad as a loading time for an app but seems a very high overhead for just declaring conflicts. Could there be a better way to declare conflicts, in an efficient way? Note: I have several .R files that are sourced in |
conflict_prefer()
is slow
I see a doubling in time, which is what I'd expect: library(conflicted)
declare_conflicts1 <- function() {
conflicted::conflict_prefer("shift",winner = "data.table",quiet = T)
conflicted::conflict_prefer("last",winner = "dplyr",quiet = T)
conflicted::conflict_prefer("first",winner = "data.table",quiet = T)
conflicted::conflict_prefer("year",winner = "lubridate",quiet = T)
conflicted::conflict_prefer("month",winner = "lubridate",quiet = T)
conflicted::conflict_prefer("day",winner = "lubridate",quiet = T)
}
declare_conflicts2 <- function() {
declare_conflicts1()
conflicted::conflict_prefer("filter",winner = "dplyr",quiet = T)
conflicted::conflict_prefer("renderDataTable", "DT",quiet = T)
conflicted::conflict_prefer("hour", "lubridate",quiet = T)
conflicted::conflict_prefer("minute", "lubridate",quiet = T)
conflicted::conflict_prefer("between", "dplyr",q = T)
}
bench::mark(
declare_conflicts1(),
declare_conflicts2(),
check = FALSE
)
#> # A tibble: 2 × 6
#> expression min median `itr/sec` mem_alloc `gc/sec`
#> <bch:expr> <bch:tm> <bch:tm> <dbl> <bch:byt> <dbl>
#> 1 declare_conflicts1() 56.4µs 58.9µs 16723. 25.6KB 52.3
#> 2 declare_conflicts2() 103.9µs 108.6µs 9078. 60.8KB 52.1 Created on 2022-10-31 with reprex v2.0.2 I think the problem is that every time you call |
Alright. I will wait for further guidance on |
I wonder how are you getting such a fast response.
If you don't mind sharing your machine config in which you ran above @hadley, it would be great to know, as the performance is several orders better in your machine than mine (I got 1140 msec compared to your Mine is an Ubuntu 20 server, 8 CPU cores, 16GB RAM. Hosted on Digital Ocean, Data center: Bengaluru. |
I have a recent macbook pro with m1 chip. |
Maybe syntax could be something like: conflicted::conficts_register({
conflicted::conflict_prefer("filter",winner = "dplyr",quiet = T)
conflicted::conflict_prefer("renderDataTable", "DT",quiet = T)
conflicted::conflict_prefer("hour", "lubridate",quiet = T)
conflicted::conflict_prefer("minute", "lubridate",quiet = T)
conflicted::conflict_prefer("between", "dplyr",q = T)
}) |
Or maybe it should be more like: conflicted::conficts_favour({
dplyr::filter,
DT::renderDataTable,
lubridate::hour,
lubridate::minute,
dplyr::between,
}) |
I re installed using |
I would do it with |
I think the new |
Thanks @hadley - i will test it let you know. We can close the issue for now. |
After consistently facing delayed sourcing times - 2 to 4 seconds (of R files that are all just functions), I added
tictoc::tic()
andtoc()
in each block of my code to narrow down to where the delays are.FInally the main delay was found in running a small bunch of
conflicted::conflict_prefer()
,So you see just those 6 lines causes a 1 second + delay in execution.
What's happening under the hood? or am I missing something?
The text was updated successfully, but these errors were encountered: