Andrew Grieve | bd10a66 | 2018-09-14 01:19:59 | [diff] [blame] | 1 | # Debugging slow builds |
| 2 | |
| 3 | Some tips for debugging slow build times: |
| 4 | * Use [ninjatracing](https://github.com/nico/ninjatracing) and chrome:tracing to |
| 5 | view a timeline of the most recent build. |
| 6 | * Many bots output a build trace (look for a `"ninja_log"` link). |
| 7 | * Use `gn gen --tracelog trace.json` to create a similar trace for `gn gen`. |
| 8 | * Depot Tool's `autoninja` has logic for summarizing slow steps. Enable it via: |
| 9 | * `NINJA_SUMMARIZE_BUILD=1 autoninja -C out/Debug my_target` |
| 10 | * Many Android templates make use of |
| 11 | [`md5_check.py`](https://cs.chromium.org/chromium/src/build/android/gyp/util/md5_check.py) |
| 12 | to optimize incremental builds. |
| 13 | * Set `PRINT_BUILD_EXPLANATIONS=1` to have these commands log which inputs |
| 14 | changed. |
| 15 | * If you suspect files are being rebuilt unnecessarily during incremental |
| 16 | builds: |
| 17 | * Use `ninja -n -d explain` to figure out why ninja thinks a target is dirty. |
| 18 | * Ensure actions are taking advantage of ninja's `restat=1` feature by not |
| 19 | updating timestamps on outputs when their content does not change. |