- 11 Jun, 2018 2 commits
-
-
Bruce Dawson authored
post_build_ninja_summary.py detects a new incremental build by looking for the end time stamps to go backwards. This means that repeated builds that have a single long step will not be reliably detected and will, in some cases, be missed entirely. This hits me sometimes when doing link testing - delete an output DLL, rebuild, and the old results may be displayed again. This change updates the script to check for a different duration for an existing record as well as an earlier end time should handle almost all cases. This also renames the targets local variable to avoid confusion due to the targets member variable of the Targets class. Bug: chromium:787983 Change-Id: I60a371df75d6cb7a55bd46b38156cb109feb8f15 Reviewed-on: https://chromium-review.googlesource.com/1061413 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
-
Daniel Bratell authored
Sometimes the log files are not named .ninja_log and then it's good if you can give the script the actual name and path. Change-Id: I59e9812c81a83ffac3ecdc8b29887e99bf71b60f Reviewed-on: https://chromium-review.googlesource.com/1012112Reviewed-by: Dirk Pranke <dpranke@chromium.org> Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Commit-Queue: Daniel Bratell <bratell@opera.com>
-
- 13 Feb, 2018 1 commit
-
-
Bruce Dawson authored
post_build_ninja_summary.py gives a summary of a ninja build. It can be run standalone or it can be run automatically by autoninja. This CL updates the Python script and the autoninja bash script to make this work on Linux. This includes removing a zero-value assert, and ensuring that .so files get categorized as such. Change-Id: I2d59ab129f5ce70117beeb119719f8432bfbab7c Reviewed-on: https://chromium-review.googlesource.com/915053Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
-
- 09 Feb, 2018 1 commit
-
-
Bruce Dawson authored
post_build_ninja_summary.py analyzes the .ninja_log file in an output directory to summarize build performance. It lists the most expensive build steps, and build-step types, printing both their elapsed time and, more importantly, their "weighted" time which is a measure of their contribution to the total build time. For each time segment within the build the running build steps accumulate weighted time that is proportional to the elapsed time divided by the number of tasks running. If a thousand compilation steps are running in parallel then they will each be "charged" for 1/1,000th of the elapsed time. If a single link step is running alone then it is charged with all of the elapsed time. Bug: chromium:787983 Change-Id: Id5aea715f798a16415dd0365a27f0051202668e5 Reviewed-on: https://chromium-review.googlesource.com/871988Reviewed-by: Dirk Pranke <dpranke@chromium.org> Reviewed-by: Erik Staab <estaab@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
-