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

Intermediate data structure to store all the code analysis #576

Merged
merged 30 commits into from
Nov 26, 2018
Merged

Conversation

wlandau
Copy link
Member

@wlandau wlandau commented Nov 9, 2018

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 make drake cleaner and faster in the long run.

Implementation

load_mtcars_example()
config <- drake_config(my_plan)
str(config$ordinances)

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 use lightly_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

  • I have read drake's code of conduct, and I agree to follow its rules.
  • I have listed any substantial changes in the development news.
  • I have added testthat unit tests to tests/testthat to confirm that any new features or functionality work correctly.
  • I have tested this pull request locally with devtools::check()
  • This pull request is ready for review.
  • I think this pull request is ready to merge.

@wlandau wlandau self-assigned this Nov 9, 2018
@wlandau
Copy link
Member Author

wlandau commented Nov 9, 2018

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-io
Copy link

codecov-io commented Nov 9, 2018

Codecov Report

Merging #576 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff           @@
##           master   #576    +/-   ##
======================================
  Coverage     100%   100%            
======================================
  Files          73     74     +1     
  Lines        6857   6754   -103     
======================================
- Hits         6857   6754   -103
Impacted Files Coverage Δ
R/clean.R 100% <100%> (ø) ⬆️
R/run.R 100% <100%> (ø) ⬆️
R/drake_graph_info_utils.R 100% <100%> (ø) ⬆️
R/checksums.R 100% <100%> (ø) ⬆️
R/hasty.R 100% <100%> (ø) ⬆️
R/triggers.R 100% <100%> (ø) ⬆️
R/deprecate.R 100% <100%> (ø) ⬆️
R/store.R 100% <100%> (ø) ⬆️
R/commands.R 100% <100%> (ø) ⬆️
R/drake_graph_info.R 100% <100%> (ø) ⬆️
... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c8d1c13...82a85e0. Read the comment docs.

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

Successfully merging this pull request may close these issues.

3 participants