tree: f0113531c973eb61c1c03f39c04d2cd188093bde [path history] [tgz]
  1. BUILD.bazel
  2. canonical_perf.sh
  3. clone.py
  4. clone.sh
  5. clone_test.py
  6. cuj.py
  7. cuj_catalog.py
  8. cuj_regex_based.py
  9. finder.py
  10. finder_test.py
  11. go_allowlists.py
  12. go_allowlists_test.py
  13. incremental_build.py
  14. incremental_build.sh
  15. perf_metrics.py
  16. perf_metrics_test.py
  17. plot_metrics.py
  18. plot_metrics.template.txt
  19. plot_metrics_test.py
  20. pretty.py
  21. pretty.sh
  22. pretty_test.py
  23. README.md
  24. ui.py
  25. util.py
  26. util_test.py
scripts/incremental_build/README.md

How to Use

The most basic invocation, e.g. incremental_build.sh --cujs "modify Android.bp$" -- libc, is logically equivalent to

  1. running m --skip-soong-tests libc and then
  2. parsing $OUTDIR/soong_metrics, $OUTDIR/bp2build_metrics.pb etc
  3. Adding timing-related metrics from step 2 into out/timing_logs/metrics.csv
  4. Now it's “warmed-up”, for each cuj:
    1. apply changes associate with the cuj
    2. repeat steps 1 through 3

CUJs are defined in cuj_catalog.py Each row in metrics.csv has the timings of various “phases” of a build.

Try incremental_build.sh --help and canoncial_perf.sh --help for help on usage.

CUJ groups

Since most CUJs involve making changes to the source code, we group a number of cujs together such that when any of them is specified, all CUJs