The *average compile time was reduced by 45%*, it went from 48.3 minutes
down to 26.6 minutes.
As a data point on November 10th, there was 185 win_rel try jobs so this
represents* an estimated saving of 64 hours *of computation power on this
Saturday alone.
This is important, the default try builders (win_rel, linux_rel, mac_rel,
linux_clang, mac_asan, etc) used to build 'all' and now build '*
chromium_builder_tests*'. If you relied on a target that wasn't included in
this target, it's not built anymore but there could still be left overs in
the build directories from the previous configuration as I didn't force a
clobber build. '*win_ash*' now builds '*aura_builder*'. Some builders like
linux_chromeos or win_layout_rel weren't changed and could enjoy some
attention but I don't know the specifics about what should be built on
these so please send me a CL to fix this.
Expect more non-linear performance improvements in the near future.
On Mon, Nov 12, 2012 at 2:56 PM, Marc-Antoine Ruel <mar...@chromium.org> wrote:
> The average compile time was reduced by 45%, it went from 48.3 minutes down
> to 26.6 minutes.
> As a data point on November 10th, there was 185 win_rel try jobs so this
> represents an estimated saving of 64 hours of computation power on this
> Saturday alone.
> What changed?
> The Try Builders used to implicitly build "all". This is not the case
> anymore with CL 11365154. Ironically I looked at it for the test isolation
> effort which is in progress (there will be news soon).
> This is important, the default try builders (win_rel, linux_rel, mac_rel,
> linux_clang, mac_asan, etc) used to build 'all' and now build
> 'chromium_builder_tests'. If you relied on a target that wasn't included in
> this target, it's not built anymore but there could still be left overs in
> the build directories from the previous configuration as I didn't force a
> clobber build. 'win_ash' now builds 'aura_builder'. Some builders like
> linux_chromeos or win_layout_rel weren't changed and could enjoy some
> attention but I don't know the specifics about what should be built on these
> so please send me a CL to fix this.
> Expect more non-linear performance improvements in the near future.
On Mon, Nov 12, 2012 at 6:56 AM, Marc-Antoine Ruel <mar...@chromium.org> wrote:
> The average compile time was reduced by 45%, it went from 48.3 minutes down
> to 26.6 minutes.
> As a data point on November 10th, there was 185 win_rel try jobs so this
> represents an estimated saving of 64 hours of computation power on this
> Saturday alone.
> What changed?
> The Try Builders used to implicitly build "all". This is not the case
> anymore with CL 11365154. Ironically I looked at it for the test isolation
> effort which is in progress (there will be news soon).
Cool!
When I suggested changing this in the past, it got rejected because
folks (you?) said that we should have at least some bot that builds
all targets. Do we have different bots for that now?
> This is important, the default try builders (win_rel, linux_rel, mac_rel,
> linux_clang, mac_asan, etc) used to build 'all' and now build
> 'chromium_builder_tests'. If you relied on a target that wasn't included in
> this target, it's not built anymore but there could still be left overs in
> the build directories from the previous configuration as I didn't force a
> clobber build. 'win_ash' now builds 'aura_builder'. Some builders like
> linux_chromeos or win_layout_rel weren't changed and could enjoy some
> attention but I don't know the specifics about what should be built on these
> so please send me a CL to fix this.
> Expect more non-linear performance improvements in the near future.
> The *average compile time was reduced by 45%*, it went from 48.3 minutes
> down to 26.6 minutes.
> As a data point on November 10th, there was 185 win_rel try jobs so this
> represents* an estimated saving of 64 hours *of computation power on this
> Saturday alone.
> This is important, the default try builders (win_rel, linux_rel, mac_rel,
> linux_clang, mac_asan, etc) used to build 'all' and now build '*
> chromium_builder_tests*'. If you relied on a target that wasn't included
> in this target, it's not built anymore but there could still be left overs
> in the build directories from the previous configuration as I didn't force
> a clobber build. '*win_ash*' now builds '*aura_builder*'. Some builders
> like linux_chromeos or win_layout_rel weren't changed and could enjoy some
> attention but I don't know the specifics about what should be built on
> these so please send me a CL to fix this.
> Expect more non-linear performance improvements in the near future.
I didn't look at the exact list of targets that are not built as I did it
not do it for performance reasons. It's more tricky issues about things
that must not be built by default; e.g. the *_run targets must not be built
unless necessary otherwise it's archiving hundreds of MB of data for no
good reason.
Only the builders on http://build.chromium.org/p/chromium/waterfall build
"all" and they are not cycling as fast as the incremental builders. Many
times I saw the try builders fails a compile because one of the target
outside of chromium_build_testers instead of the reverse.
We didn't want to do it before because it's still a dangerous move but
overall, the trade off of keeping 'all' by default is not worth as shown in
the performance improvement alone. We can reverse the change if it becomes
a problem in practice.
I left the linux_rel_naclmore, mac_rel_naclmore and win_rel_naclmore to
continue building "all" so you can use these non-default try builders to
check out anything exotheric. An option if it becomes a problem is to leave
a by default "compile all" alternate builder in the CQ.
Ping me if you see tree breakage because of a target outside
chromium_build_testers so we can decide if we need to add back 'all'
compilation on the CQ.
> When I suggested changing this in the past, it got rejected because
> folks (you?) said that we should have at least some bot that builds
> all targets. Do we have different bots for that now?
Ah, I didn't know that only the clobber builders build 'all'. In that case,
if the trybots are just like the incremental builders that seems like a
much smaller divergence.
Sounds good to track how often this leads to breakages to see if it's an
issue in practice.
On Mon, Nov 12, 2012 at 8:51 AM, Marc-Antoine Ruel <mar...@chromium.org>wrote:
> I didn't look at the exact list of targets that are not built as I did it
> not do it for performance reasons. It's more tricky issues about things
> that must not be built by default; e.g. the *_run targets must not be built
> unless necessary otherwise it's archiving hundreds of MB of data for no
> good reason.
> Only the builders on http://build.chromium.org/p/chromium/waterfall build
> "all" and they are not cycling as fast as the incremental builders. Many
> times I saw the try builders fails a compile because one of the target
> outside of chromium_build_testers instead of the reverse.
> We didn't want to do it before because it's still a dangerous move but
> overall, the trade off of keeping 'all' by default is not worth as shown in
> the performance improvement alone. We can reverse the change if it becomes
> a problem in practice.
> I left the linux_rel_naclmore, mac_rel_naclmore and win_rel_naclmore to
> continue building "all" so you can use these non-default try builders to
> check out anything exotheric. An option if it becomes a problem is to leave
> a by default "compile all" alternate builder in the CQ.
> Ping me if you see tree breakage because of a target outside
> chromium_build_testers so we can decide if we need to add back 'all'
> compilation on the CQ.
>> When I suggested changing this in the past, it got rejected because
>> folks (you?) said that we should have at least some bot that builds
>> all targets. Do we have different bots for that now?
> 2012/11/12 John Abd-El-Malek <j...@chromium.org>
>> Do you know which big binaries that we save building?
>> I thought we didn't want to build only a subset on the trybots because
>> then that could lead to build failures on buildbots after commit?
On Mon, Nov 12, 2012 at 6:02 PM, John Abd-El-Malek <j...@chromium.org> wrote:
> Ah, I didn't know that only the clobber builders build 'all'. In that
> case, if the trybots are just like the incremental builders that seems like
> a much smaller divergence.
> Sounds good to track how often this leads to breakages to see if it's an
> issue in practice.
> On Mon, Nov 12, 2012 at 8:51 AM, Marc-Antoine Ruel <mar...@chromium.org>wrote:
>> I didn't look at the exact list of targets that are not built as I did it
>> not do it for performance reasons. It's more tricky issues about things
>> that must not be built by default; e.g. the *_run targets must not be built
>> unless necessary otherwise it's archiving hundreds of MB of data for no
>> good reason.
>> Only the builders on http://build.chromium.org/p/chromium/waterfallbuild "all" and they are not cycling as fast as the incremental builders.
>> Many times I saw the try builders fails a compile because one of the target
>> outside of chromium_build_testers instead of the reverse.
>> We didn't want to do it before because it's still a dangerous move but
>> overall, the trade off of keeping 'all' by default is not worth as shown in
>> the performance improvement alone. We can reverse the change if it becomes
>> a problem in practice.
>> I left the linux_rel_naclmore, mac_rel_naclmore and win_rel_naclmore to
>> continue building "all" so you can use these non-default try builders to
>> check out anything exotheric. An option if it becomes a problem is to leave
>> a by default "compile all" alternate builder in the CQ.
>> Ping me if you see tree breakage because of a target outside
>> chromium_build_testers so we can decide if we need to add back 'all'
>> compilation on the CQ.
>>> When I suggested changing this in the past, it got rejected because
>>> folks (you?) said that we should have at least some bot that builds
>>> all targets. Do we have different bots for that now?
>> 2012/11/12 John Abd-El-Malek <j...@chromium.org>
>>> Do you know which big binaries that we save building?
>>> I thought we didn't want to build only a subset on the trybots because
>>> then that could lead to build failures on buildbots after commit?
> Does this mean we need to update a target, or maybe not run this on the
> linux_rel trybot?
> On Mon, Nov 12, 2012 at 6:02 PM, John Abd-El-Malek <j...@chromium.org>wrote:
>> Ah, I didn't know that only the clobber builders build 'all'. In that
>> case, if the trybots are just like the incremental builders that seems like
>> a much smaller divergence.
>> Sounds good to track how often this leads to breakages to see if it's an
>> issue in practice.
>> On Mon, Nov 12, 2012 at 8:51 AM, Marc-Antoine Ruel <mar...@chromium.org>wrote:
>>> I didn't look at the exact list of targets that are not built as I did
>>> it not do it for performance reasons. It's more tricky issues about things
>>> that must not be built by default; e.g. the *_run targets must not be built
>>> unless necessary otherwise it's archiving hundreds of MB of data for no
>>> good reason.
>>> Only the builders on http://build.chromium.org/p/chromium/waterfallbuild "all" and they are not cycling as fast as the incremental builders.
>>> Many times I saw the try builders fails a compile because one of the target
>>> outside of chromium_build_testers instead of the reverse.
>>> We didn't want to do it before because it's still a dangerous move but
>>> overall, the trade off of keeping 'all' by default is not worth as shown in
>>> the performance improvement alone. We can reverse the change if it becomes
>>> a problem in practice.
>>> I left the linux_rel_naclmore, mac_rel_naclmore and win_rel_naclmore to
>>> continue building "all" so you can use these non-default try builders to
>>> check out anything exotheric. An option if it becomes a problem is to leave
>>> a by default "compile all" alternate builder in the CQ.
>>> Ping me if you see tree breakage because of a target outside
>>> chromium_build_testers so we can decide if we need to add back 'all'
>>> compilation on the CQ.
>>>> When I suggested changing this in the past, it got rejected because
>>>> folks (you?) said that we should have at least some bot that builds
>>>> all targets. Do we have different bots for that now?
>>> 2012/11/12 John Abd-El-Malek <j...@chromium.org>
>>>> Do you know which big binaries that we save building?
>>>> I thought we didn't want to build only a subset on the trybots because
>>>> then that could lead to build failures on buildbots after commit?
