-
Notifications
You must be signed in to change notification settings - Fork 129
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
Intermediate data structure to store all the code analysis #576
Conversation
to function internals. Related: #345
A quick performance study using the overhead example (ref: #498): library(drake)
library(microbenchmark)
library(storr)
# See vis_drake_graph(drake_config(plan(8)), targets_only = TRUE)
plan <- function(n){
plan <- drake_plan(target_1 = 1)
for (i in seq_len(n - 1) + 1){
target <- paste0("target_", i)
dependencies <- paste0("target_", seq_len(i - 1))
command <- paste0("max(", paste0(dependencies, collapse = ", "), ")")
plan <- rbind(plan, data.frame(target = target, command = command))
}
plan
}
cache <- function(n){
path <- file.path(tempdir(), paste0("cache", n))
cache <- storr_rds(path, mangle_key = TRUE)
clean(cache = cache)
cache
}
overhead <- function(n){
make(plan(n), cache = cache(n), verbose = 4)
}
system.time(overhead(1024)) Runtime with a63f1dc (this PR): user system elapsed
161.540 6.520 171.298 Runtime with e356a0d (current master branch): user system elapsed
160.460 6.360 168.793 So no clear performance gain or loss at the moment. Either this PR does not speed things up or other bottlenecks are masking the boost. |
Codecov Report
@@ Coverage Diff @@
## master #576 +/- ##
======================================
Coverage 100% 100%
======================================
Files 73 74 +1
Lines 6857 6754 -103
======================================
- Hits 6857 6754 -103
Continue to review full report at Codecov.
|
Summary
One major difference between
drake
and most other pipeline tools is that users declare dependencies implicitly in their plans and workspaces. Other pipeline tools like Make declare dependencies explicitly with rigorous build rules. The jump from implicit components to explicit dependency information is time-consuming and nontrivial, so in addition to the workflow plan data frame, I think we need a special data structure whose sole purpose is to store the full dependency detection results of the code analysis. I believe this will pave the way to makedrake
cleaner and faster in the long run.Implementation
This data structure is a list, and each element corresponds to a target or import. Each target's corresponding element of
ordinances
has the complete specification of immediate dependencies (other targets, output files, input files, etc.) the trigger, and all the fields of the workflow plan data frame for fast lookup.config$ordinances
is a list. I thought about making it an environment so lookup would be even faster, but then we would not be able to uselightly_paralleize()
to run through it. I am open to other suggestions. Either way, lookup should be constant-time, and we might see a little improved performance.Plans for merging
I will be on vacation from November 15 through 27, and I will wait to merge this PR until I come back. I want to be present to address any bug reports, and I want more time to think about the name. "Ordinances" is a good initial name because it is distinctive and thus easy to
sed
out later, but I am not totally sold on it.Related discussion and issues
This PR implements #440, and I believe this is essentially what @gmbecker originally suggested in #504. #498 and #575 is also related.
cc @krlmlr
Checklist
drake
's code of conduct, and I agree to follow its rules.testthat
unit tests totests/testthat
to confirm that any new features or functionality work correctly.devtools::check()