Lines Matching refs:to

17 soong_ui logs the wall time of the longest dependency chain compared to the
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.
68 `$(shell)` commands need to be re-executed to determine if their output changed.
89 other "(regen)" numbers add up to more than that (some parts are parallelized
94 All the longest commands in this case are all variants of a call to `find`, but
95 this is where using pure make functions instead of calling out to the shell can
96 make a performance impact -- many calls to check if `26 > 20` can add up. We've
97 added some basic math functions in `math.mk` to help some common use cases that
98 used to be rather expensive when they were used too often.
102 into glob or stat checks (falling back to calling `find` if one of those imply
104 that Kati can understand, but if you're writing your own, you may want to
113 It may be more efficient to move the grep into make, so that the `find` portion
120 Others can be simplified by just switching to an equivalent find command that
127 By adding the implicit `-a` and moving the `| sort` to Make, this can now be
139 Kati prints out what triggered the slow path to be taken -- this can be a
150 data to understand.
154 Kati will now dump out information about which Makefiles took the most time to
179 for any makefile to be printed with `$(KATI_profile_makefile)`:
185 With these primitives, it's possible to get the timing information for small
186 chunks, or even single lines, of a makefile. Just move the lines you want to
188 new makefile. It's possible to analyze where the time is being spent by doing
189 a binary search using this method, but you do need to be careful not to split
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
198 beginning, as this much data can be hard to read:
220 You'll likely need to cross-reference this data against the build graph in the
227 the performance is probably more related to how much time the actual build
232 to help in this area yet. It's possible to aggregate some of the raw data
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
245 Soong always loads the entire module graph, so as modules convert from Make to
246 Soong, `mm` is becoming closer to `mma`. This produces more correct builds, but
247 does slow down builds, as we need to verify/produce/load a larger build graph.
255 every incremental build, even if there was nothing to do. This was fixed in
257 significant to backport at the time. And while they fix this particular issue,
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