DescriptionRevert of Enable incremental linking for static_library too (patchset #2 id:20001 of https://codereview.chromium.org/502993005/)
Reason for revert:
Does not appear to work well for waterfall workload, see number of instances of "performing full link" in http://build.chromium.org/p/chromium.win/builders/Win%20Builder/builds/2780/steps/compile/logs/stdio
Might still be worth investigating if it's worthwhile on trybots where less things might change per-job? But doesn't seem that likely.
Original issue's description:
> Enable incremental linking for static_library too
>
> Timings on z620:
>
> Without:
>
> GYP_DEFINES=component=static_library chromium_win_pch=0 incremental_chrome_dll=0
>
> touch content\app\main.cc (causes chrome.dll, chrome_child.dll, and unit_tests.exe to relink)
> tim ninja -C out\Release unit_tests
> [19/19] LINK_EMBED unit_tests.exe
>
> real: 4m46.828s
>
> With:
>
> GYP_DEFINES=component=static_library branding=Chrome chromium_win_pch=0 incremental_chrome_dll=1
>
> touch content\app\content_main.cc && tim ninja -C out\Release unit_tests
> ninja: Entering directory `out\Release'
> [19/19] LINK_EMBED unit_tests.exe
>
> real: 0m43.625s
>
> This is basically best case, and the actual performance on bots will differ based on
> their config and the number of files that change from run-to-run, but it seems worth
> enabling to see what happens, at least.
>
> R=jam@chromium.org
> BUG=404809, 402270
>
> Committed: https://crrev.com/6922bc1d4b0a2f4604598082a877d3add6d86d1c
> Cr-Commit-Position: refs/heads/master@{#295786}
TBR=jam@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=404809, 402270
Committed: https://crrev.com/f01a9aee4db445d8f920ae191f27f0e52c76b50c
Cr-Commit-Position: refs/heads/master@{#295815}
Patch Set 1 #
Created: 6 years, 3 months ago
(Patch set is too large to download)
Messages
Total messages: 5 (0 generated)
|