azure: Get build times on par with Travis #61185
Labels
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
Comments
alexcrichton
added
T-infra
|
Ok to expand on the comment linked above, I've run azure again but this time with step timings enabled for the no assertions build, yielding this chart: https://gist.github.com/alexcrichton/46531c79f85fc213c9cd9f7417c3b1ec Here are some comparisons of build times between Travis/Appveyor to Azure. A Build time discrepancies of dist-i686-msvc:Build time discrepancies of dist-x86_64-appleBuild time discrepancies of dist-x86_64-linux-altFrom this all I can really see is that everything is just blanket slower on Azure, namely compiling rustc. That makes sense since compiling rustc is quite parallel already. It also doesn't look like azure is doing anything Travis/AppVeyor isn't by accident, and furthermore they're configured the same. All-in-all I don't really see a great win for us to cash in on here. |
|
Your "chart" has a Python backtrace at the end of the table. Two stupid questions:
|
|
Digging further into the build logs of MSVC it looks like we're building really big crates like Cargo and rustc-ap-syntax twice. That'll save 10-ish minutes of build time so I'm going to investigate why that's coming up and how to prevent it. @lnicola it depends on the builder for whether assertions are enabled or not. There is a different number of cores between the services, where we're using 4 on Travis/AppVeyor and only 2 on Azure. |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Jun 6, 2019
This shaves of 50 minutes of cycle time on Azure and will likely also save a significant chunk of time on Travis. The assertions here aren't really buying us much over other builders with assertions already enabled, so let's disable them for this builder. cc rust-lang#61185
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Jun 6, 2019
The purpose of distcheck is to test `./x.py test` from a tarball, not to test that all assertions pass all the time. These assertions are largely just redundant with other builders, so skip the assertions for now and save a good chunk of time on CI. cc rust-lang#61185
Centril
added a commit
to Centril/rust
that referenced
this issue
Jun 7, 2019
…=pietroalbini ci: Disable LLVM/debug assertions for asmjs builder This shaves of 50 minutes of cycle time on Azure and will likely also save a significant chunk of time on Travis. The assertions here aren't really buying us much over other builders with assertions already enabled, so let's disable them for this builder. cc rust-lang#61185
Centril
added a commit
to Centril/rust
that referenced
this issue
Jun 7, 2019
…=pietroalbini ci: Disable LLVM/debug assertions for asmjs builder This shaves of 50 minutes of cycle time on Azure and will likely also save a significant chunk of time on Travis. The assertions here aren't really buying us much over other builders with assertions already enabled, so let's disable them for this builder. cc rust-lang#61185
bors
added a commit
that referenced
this issue
Jun 12, 2019
…albini ci: Disable LLVM/debug assertions for distcheck The purpose of distcheck is to test `./x.py test` from a tarball, not to test that all assertions pass all the time. These assertions are largely just redundant with other builders, so skip the assertions for now and save a good chunk of time on CI. cc #61185
|
We've since switched to azure, so I don't think this issue is serving much any more, so I'm going to close. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the build times for Azure Pipelines are through the roof compared to Travis, taking up to an hour longer on relevant builds. The original PR has some measurements.
We're going to have to rework quite a lot I think to get the current 2-core within our time limits. We're shooting to have everything in 2h on a good day, and up to 3h if necessary to do things like rebuild caches and such.
The text was updated successfully, but these errors were encountered: