Full debug builds take 10% longer with gn than with gyp (on windows) |
|||||
Issue descriptionI switched some clang tot bots (which always do clobber builds) to gn. This increased the time they need to compile everything by 10 minutes. (As far as I can tell, this doesn't happen for release builds.)
,
May 11 2016
What bot(s) were these from? Were they building `all`? If so, I'd expect at least some of this to be due to the fact that all is simply bigger in GN builds due to including more targets and there being some number of GN-only targets. That said, I don't know that that would account for a 10% increase ...
,
May 11 2016
,
May 11 2016
Yes, 'all'. Sorry, should've included a link: https://build.chromium.org/p/chromium.fyi/stats/ClangToTWin(dbg) https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin(dbg) While it's true that gyp's 'all' omits some stuff, I don't think we ported those missing targets to gn.
,
May 12 2016
For anyone playing along at home, two green builds: https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin%28dbg%29/builds/5567 (gn, 122 min) https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin%28dbg%29/builds/5568 (gyp, 113 min) There are 33873 edges in GYP, 37331 in GN, but given that NaCl works much differently in GN it's hard to infer too much from that. In theory building 'both_gyp_and_gn' should build exactly the same list of targets, but in practice I haven't audited that on Windows yet.
,
May 12 2016
gn visualization: http://chromium-build-stats.appspot.com/ninja_log/2016/05/10/build128-m1/ninja_log.build128-m1.chrome-bot.20160510-082650.8020.gz gyp visualization: http://chromium-build-stats.appspot.com/ninja_log/2016/05/10/build128-m1/ninja_log.build128-m1.chrome-bot.20160510-133010.3116.gz (from the bottom of the compile logs of these two builds). The trace view doesn't load for me for the gn build (filed bug 611269 for that). After spot-checking the two table views, nothing jumped out at me.
,
Jun 20 2016
I expect this is largely due to the source_set / static_library issues we've been looking at lately. @brucedawson, do you want to own this and/or decide when we want to call this "close enough"? I don't think this needs to block the migration at this point, but someone should speak up (or re-add 354261 and/or 498033 to the list of blocking bugs) if they disagree.
,
Jun 21 2016
Seems like a good one for me to own.
,
Nov 22 2017
This is way past being something that I can investigate in this manner. However work is continuing on identifying build bottlenecks and improving them. Closing this one. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by thakis@chromium.org
, May 10 2016