Slow startup on Windows

[Vlad-Shcherbina]

To reproduce:

1. Download rustup-init.exe from https://www.rustup.rs/.
2. Run it to install Rust.
3. Run rustup --version.

Expected: this command to print its version ("rustup 1.10.0 (c6a8f7c 2018-01-25)") and exit instantly.

Actual behavior: this command takes about one second to print version and exit.

---

To investigate, I tried building rustup from source. I ran the following commands:

git clone git@github.com:rust-lang-nursery/rustup.rs.git
cd rustup.rs
cargo build --release
copy .\target\release\rustup-init.exe .\rustup.exe

And then

.\rustup.exe --version

Locally built rustup starts up instantly. The size of the executable is 6MB (for comparison, the official download is 13MB). Could it be that the official download was produced for the wrong configuration (debug build or something)?

I used the following compiler to build it:

> rustc --version --verbose
rustc 1.25.0-nightly (29c8276ce 2018-02-07)
binary: rustc
commit-hash: 29c8276cee4a0eab7e0634ff25c6b47bd9f87c6c
commit-date: 2018-02-07
host: x86_64-pc-windows-msvc
release: 1.25.0-nightly
LLVM version: 4.0

[steffengy]

Possibly related to rust-lang/cargo#5028.
Atleast for me locally disabling windows defender makes those commands (including rustup --version) finish immediately, with it enabled it takes a few seconds.

Is that also the case on your end?

[steffengy]

@alexcrichton
Using either:

• https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe
• https://static.rust-lang.org/rustup/archive/1.10.0/x86_64-pc-windows-msvc/rustup-init.exe

as rustup.exe is faster (without the noticed delay)
Strangely those binaries are only 5.7 MB while my local rustup 1.10.0 is ~12 MB.

Did we previously ship debug builds or does rustup download another binary for self-update?

[alexcrichton]

@steffengy whoa interesting! I think the difference you're seeing is MSVC vs MinGW. I think we ship x86_64-pc-windows-gnu binaries by default? If it's true though that MSVC is faster we should certainly change that!

[steffengy]

@alexcrichton
That doesn't seem to be the issue.

26.01.2018  00:18        13.124.774 rustup.exe
12.02.2018  23:16        13.323.777 rustupgnu.exe

The GNU version is fast too.
https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-gnu/rustup-init.exe

[steffengy]

Seems like the slow version I have locally is the x86 GNU version:
https://static.rust-lang.org/rustup/dist/i686-pc-windows-gnu/rustup-init.exe

which indeed seems much slower.
It might anyways make sense to ship the MSVC instead (or atleast the x64 GNU)

[alexcrichton]

Ah yes I just checked and we were defaulting to i686-pc-windows-gnu because I believe long ago the MSVC target brought in more dylib dependencies. Nowadays though the MSVC is compiled with the static CRT, so I just switched it to install MSVC by default from the website!

[steffengy]

That should atleast fix it for new installations.

How do we fix that for existing installations though?
Some users surely will just redownload it, if they find this thread.
But most of them wont and will be stuck on (potentially slow) x86-rustup builds for a long time.

Any better option than making rustup updates prompt for a switch to x86_64 builds on x64-capable systems?

[alexcrichton]

Nah I think it's definitely a possibility to auto-switch over. I think we could add support for "if you're i686-pc-windows-gnu download i686-pc-windows-msvc instead", I don't believe there are any remaining reasons to use i686-pc-windows-gnu rustup binaries any more

[steffengy]

Interestingly it's really an architecture problem (i686-msvc builds show the same delay).
So I'd lean towards just switching to x64-msvc-builds on x64 systems.

I'll spin up a PR for that tomorrow, if nobody gets to it first :)

[alexcrichton]

Oh! Sorry I misunderstood. So actually for x86_64 we'll need two fixes. The first is to rustup itself to download the MSVC version in the future, and the second is to rustup.rs (the website) itself. I'm... not sure how do do the latter though. I think I forget how it's even deployed...

[steffengy]

The first is to rustup itself to download the MSVC version in the future

That's what I plan to submit a PR for.

the second is to rustup.rs (the website) itself

The website currently seems to ship i686-msvc for me.
If we can't figure out how to get that updated soon,
we could first also fallback to just running an update initially after the rustup bootstrap,
(if that isn't the case anyways) which then downloads the appropriate rustup version...

[alexcrichton]

@steffengy ah yeah the website unconditionally ships one version, and I just updated an nginx rewriting rule to unconditionally return i686-msvc. Somewhere the website links to https://win.rustup.rs and that location needs to be changed to auto-detect 32/64 bit and redirect to links we manufactur (like https://win.rustup.rs/x86_64 or something like that)

[steffengy]

Seems to be deployed via travis (potentially at least):

https://github.com/rust-lang-nursery/rustup.rs/blob/master/ci/prepare-deploy-travis.sh#L54

link at:
https://github.com/rust-lang-nursery/rustup.rs/blob/master/www/index.html#L34

I guess the part with https://win.rustup.rs/x86_64 is something you can also handle via NGINX?

[alexcrichton]

Oh great! I've just updated win.rustup.rs, so the x86_64 and i686 paths should return the respective binaries

[rbtcollins]

So this seems to be solved yes? We're shipping the MSVC binary by default everywhere? I think we can close this ticket, as making the gnu binary faster isn't a rustup project issue, rather its a rustlang toolchain issue.

[rbtcollins]

I'll take that thumbs up as a yes :).