Lines Matching +full:ninja +full:- +full:build
1 # Build Performance
3 ## Debugging Build Performance
7 soong_ui has tracing built in, so that every build execution's trace can be
8 viewed. Just open `$OUT_DIR/build.trace.gz` in Chrome's <chrome://tracing>, or
10 stored in `build.trace.#.gz` (larger numbers are older). The associated logs
24 …0:00 build out/target/product/generic_arm64/obj/FAKE/sepolicy_neverallows_intermediates/policy_2.c…
25 …0:04 build out/target/product/generic_arm64/obj/FAKE/sepolicy_neverallows_intermediates/sepolicy_n…
26 …0:13 build out/target/product/generic_arm64/obj/ETC/plat_sepolicy.cil_intermediates/plat_sepolicy.…
27 …0:01 build out/target/product/generic_arm64/obj/ETC/plat_pub_versioned.cil_intermediates/plat_pub_…
28 …0:02 build out/target/product/generic_arm64/obj/ETC/vendor_sepolicy.cil_intermediates/vendor_sepol…
29 0:16 build out/target/product/generic_arm64/obj/ETC/sepolicy_intermediates/sepolicy
30 …0:00 build out/target/product/generic_arm64/obj/ETC/plat_seapp_contexts_intermediates/plat_seapp_c…
32 0:02 build out/target/product/generic_arm64/obj/NOTICE.txt
33 0:00 build out/target/product/generic_arm64/obj/NOTICE.xml.gz
34 0:00 build out/target/product/generic_arm64/system/etc/NOTICE.xml.gz
35 0:01 Installed file list: out/target/product/generic_arm64/installed-files.txt
39 …/product/generic_arm64/obj/PACKAGING/target_files_intermediates/aosp_arm64-target_files-6663974.zip
40 0:01 Package: out/target/product/generic_arm64/aosp_arm64-img-6663974.zip
41 …0:01 Dist: /buildbot/dist_dirs/aosp-master-linux-aosp_arm64-userdebug/6663974/aosp_arm64-img-66639…
45 parallelism on the build machine will improve total build times. If there are
46 long individual times listed in the critical path then improving build times
48 in the build graph will improve total build times.
53 the `-cpuprofile`, `-trace`, and `-memprofile` command line arguments, but we
54 don't currently have an easy way to enable them in the context of a full build.
59 performance sensitive, since it doesn't need to happen on every build. It is
60 important for the fast-path (detecting whether it needs to regenerate the ninja
61 file) to be fast however. And it shouldn't hit the slow path too often -- so
63 or read a file that's going to change on every build.
67 In most cases, we've found that the fast-path is slow because all of the
68 `$(shell)` commands need to be re-executed to determine if their output changed.
75 … 1 mkdir -p out/target/product/generic && echo Android/aosp_arm/generic:R/AOSP.MASTER/$(date -d @$…
77 …10 / 1 cd cts/tests/framework/base/windowmanager ; find -L * -name "Components.java" -and -not -n…
78 verbose: *kati*: 0.010 / 1 git -C test/framework/build log -s -n 1 --format="%cd" --date=format:"…
79 … cd development/samples/ShortcutDemo/publisher ; find -L ../common/src -name "*.java" -and -not -…
80 …2 cd development/samples/ShortcutDemo/launcher ; find -L ../common/src -name "*.java" -and -not -…
81 verbose: *kati*: 0.009 / 1 if ! cmp -s out/target/product/generic/obj/CONFIG/kati_packaging/dist.…
82 …bose: *kati*: 0.008 / 1 mkdir -p out/target/product/generic && echo R/AOSP.MASTER/$(cat out/buil…
84 verbose: *kati*: 0.007 / 1 uname -sm
91 -- in this case, 66 calls took 0.27s. The top 10 longest shell functions are
96 make a performance impact -- many calls to check if `26 > 20` can add up. We've
100 There are some optimizations in place for find commands -- if Kati can
101 understand the find command, the built-in find emulator can turn some of them
110 …: *kati*: 0.015 cd libcore && (find luni/src/test/java -name "*.java" 2> /dev/null) | grep -v -f …
117 $(filter-out $(file <$(LOCAL_PATH)/java_tests_blacklist),$(call all-java-files-under,luni/src/test/…
124 …o:127: *kati*: 0.217 find device vendor -type f -name \*.pk8 -o -name verifiedboot\* -o -name \*.…
127 By adding the implicit `-a` and moving the `| sort` to Make, this can now be
131 $(sort $(shell find device vendor -type -f -a -name \*.pk8 -o -name verifiedboot\* -o -name \*.x509…
134 Kati has now learned about the implicit `-a`, so this particular change is no
139 Kati prints out what triggered the slow path to be taken -- this can be a
144 out/soong/Android-aosp_arm.mk was modified, regenerating...
148 read with the `ckati_stamp_dump` tool in prebuilts/build-tools. More debugging
149 is available when ckati is run with `--regen_debug`, but that can be a lot of
159 verbose: *kati*: 18.389 / 1 out/soong/Android-aosp_arm.mk
160 verbose: *kati*: 13.137 / 20144 build/make/core/soong_cc_prebuilt.mk
161 verbose: *kati*: 11.743 / 27666 build/make/core/base_rules.mk
163 verbose: *kati*: 2.054 / 1 art/build/Android.cpplint.mk
164 verbose: *kati*: 1.955 / 28269 build/make/core/clear_vars.mk
165 verbose: *kati*: 1.795 / 283 build/make/core/package.mk
166 verbose: *kati*: 1.790 / 283 build/make/core/package_internal.mk
167 verbose: *kati*: 1.757 / 17382 build/make/core/link_type.mk
168 verbose: *kati*: 1.078 / 297 build/make/core/aapt2.mk
172 spent of 13.137 secounds. While Android-aosp_arm.mk was only included once, and
173 took 18.389 seconds. In this case, Android-aosp_arm.mk is the only file that
175 in Android-aosp_arm.mk was actually spent within soong_cc_prebuilt.mk (or
182 $(KATI_profile_makefile build/make/core/product.mk)
192 ### Ninja subsection
196 Add `NINJA_ARGS="-d explain"` to your environment before a build, this will cause
197 ninja to print out explanations on why actions were taken. Start reading from the
204 $ NINJA_ARGS="-d explain" mma
206 ninja explain: output out/soong/.intermediates/art/tools/cpp-define-generator/cpp-define-generator-…
208 ninja explain: out/soong/.intermediates/art/tools/cpp-define-generator/cpp-define-generator-data/li…
209 ninja explain: out/soong/.intermediates/art/tools/cpp-define-generator/cpp-define-generator-data/li…
210 ninja explain: out/soong/host/linux-x86/bin/cpp-define-generator-data is dirty
211 ninja explain: out/soong/.intermediates/art/tools/cpp-define-generator/cpp-define-generator-asm-sup…
212 ninja explain: out/soong/.intermediates/art/cmdline/art_cmdline_tests/android_arm_armv7-a_core_cmdl…
217 asm_support_gen.h, which was generated by cpp-define-generator-data, which uses
220 You'll likely need to cross-reference this data against the build graph in the
221 various .ninja files. The files are (mostly) human-readable, but a (slow) web
222 interface can be used by running `NINJA_ARGS="-t browse <target>" m`.
226 If the long part in the trace view of a build is a relatively solid block, then
227 the performance is probably more related to how much time the actual build
229 soong/kati/ninja themselves.
234 for build commands to impact unrelated build commands. This is an area we'd
235 like to improve -- we expect keeping track of user/system time per-action would
236 provide more reliable data, but tracking some full-system data (memory/swap
247 does slow down builds, as we need to verify/produce/load a larger build graph.
249 As of Android Q, loading large build graphs is fast, and in Android R, `mm` is
255 every incremental build, even if there was nothing to do. This was fixed in
258 they appear to cause ninja to spend more time during every build loading the
261 A workaround to get out of this state is to remove the build.ninja entry from
265 sed -i "/\/build.ninja/d" $(get_build_var OUT_DIR)/.ninja_log
268 [catapult trace_viewer]: https://github.com/catapult-project/catapult/blob/master/tracing/README.md
269 [ninja parse optimization]: https://android-review.googlesource.com/c/platform/external/ninja/+/461…
270 [blueprint_microfactory]: https://android-review.googlesource.com/q/topic:%22blueprint_microfactory…