Run a parallel pre-check before updating toolchains by FranciscoTGouveia · Pull Request #4752 · rust-lang/rustup

FranciscoTGouveia · 2026-03-15T20:40:33Z

Instead of sequentially checking each toolchain for updates, rustup update now first checks all toolchains concurrently and only then performs the updates (if needed).

This brings two advantages:

A no-op rustup update is now ~2x faster (see below);
After updating a toolchain, there is no need to wait for the remaining toolchains to be checked for updates; this is especially helpful in cases where only nightly needs updating.

Benchmarks were run using hyperfine (20 iterations on a 50 Mbps connection) on a setup with 11 toolchains, and no regressions were observed.
For the no-op rustup update, this patch was 2.2x faster; for cases where a single toolchain was updated, there was no measurable difference.

CC @epage

src/cli/common.rs

FranciscoTGouveia · 2026-03-15T20:42:30Z

src/cli/common.rs

+        future::join_all(channels.iter().map(|(_, d)| d.show_dist_version()))
+            .await
+            .into_iter()
+            .map(|v| v.map_or(true, |opt| opt.is_some()))
+            .collect()
+    };


Is there a cleaner way to achieve this?

Am I reading it right that now for every toolchain that needs to be updated, the update is checked twice?

Yes, I forgot to add a comment about this, sorry.

I see two possible ways to proceed:

Accept the cost of performing a double check. In practice, since the first check is done concurrently in a batch, the overhead should be relatively small.

Do a small refactor, starting in DistOptions::install_into(), to allow skipping the second check.

@FranciscoTGouveia I think we should try to avoid double checking if the changes involved are not super disruptive 🙏

I have been thinking about this, and my initial idea was to add a new manifest field (of type ManifestV2) to the DistOptions struct; however, I believe that would change the semantics quite a bit, since it would store more than just "options".

A direction I am more inclined toward is to reuse the manifest returned by show_dist_version(), which is currently discarded since we only call .is_some() on it.
Pairing this with a potential new install_with_manifest() method in InstallMethod (alongside the existing install()) would allow us to skip re-downloading the manifest.
What do you think?

A direction I am more inclined toward is to reuse the manifest returned by show_dist_version(), which is currently discarded since we only call .is_some() on it.
Pairing this with a potential new install_with_manifest() method in InstallMethod (alongside the existing install()) would allow us to skip re-downloading the manifest.
What do you think?

Sounds pretty good to me.

A direction I am more inclined toward is to reuse the manifest returned by show_dist_version(), which is currently discarded since we only call .is_some() on it. Pairing this with a potential new install_with_manifest() method in InstallMethod (alongside the existing install()) would allow us to skip re-downloading the manifest. What do you think?

@FranciscoTGouveia Yeah I agree with that. It'd be nice if the old installation method can be refactored to use the newly-introduced one by fetching the manifests before the call. I imagine there shouldn't be a lot of dependency issues in doing so?

src/cli/common.rs

djc · 2026-03-16T08:58:46Z

src/cli/common.rs

+        join_all(channels.iter().map(|(_, d)| d.show_dist_version()))
+            .await
+            .into_iter()
+            .map(|v| v.map_or(true, |opt| opt.is_some()))


I'm confused by this logic. show_dist_version() seems to merely yield the latest available version, but that a DistributableToolchain has a manifest with a rust component with a version is_some() doesn't mean that it's newer than the installed version?

Sorry, I do not think I fully understood your comment.
The rationale for using show_dist_version() comes from how it's used in rustup check.
As I understand it, show_dist_version() only returns Some when the hashes do not match (i.e., there is an update available), which aligns with what we need here.

In this setup, for toolchains that do not require updating, we would never reach .get_rust_version(), since .dl_v2_manifest() returned None.

Apologies if I've misunderstood or overlooked anything.

As I understand it, show_dist_version() only returns Some when the hashes do not match (i.e., there is an update available), which aligns with what we need here.

You're completely right. Might be good to add a docstring for show_dist_version() and maybe consider renaming it.

Sounds good, I will take care of it. :)

The Option<> semantics still remain unclear. Maybe try updated_dist_{manifest,version}()?

…ifests

rami3l · 2026-03-17T20:49:29Z

src/dist/mod.rs

                self.targets,
                &mut fetched,
                self.cfg,
+                prefetched_manifest.take(),


Question: How is this different from just passing manifest by move?

rami3l · 2026-03-17T20:55:50Z

src/cli/common.rs

+        join_all(channels.iter().map(|(_, d)| d.show_dist_version()))
+            .await
+            .into_iter()
+            .map(|v| v.map_or(true, |opt| opt.is_some()))


The Option<> semantics still remain unclear. Maybe try updated_dist_{manifest,version}()?

FranciscoTGouveia requested review from djc and rami3l March 15, 2026 20:40

FranciscoTGouveia commented Mar 15, 2026

View reviewed changes

FranciscoTGouveia force-pushed the update-performance branch from 18df18c to d6cc274 Compare March 15, 2026 21:34

djc reviewed Mar 16, 2026

View reviewed changes

FranciscoTGouveia force-pushed the update-performance branch from d6cc274 to 5332ad0 Compare March 17, 2026 17:58

FranciscoTGouveia added 2 commits March 17, 2026 17:58

fix(toolchain): extract manifest fetching out of show_dist_version()

b10a7dd

feat(install): add install_with_manifest() to reuse pre-fetched man…

4a68765

…ifests

FranciscoTGouveia force-pushed the update-performance branch from 5332ad0 to 58defd5 Compare March 17, 2026 17:58

FranciscoTGouveia requested review from ChrisDenton and djc March 17, 2026 18:15

feat(toolchain): run a pre-check before updating all toolchains

3afbe36

FranciscoTGouveia force-pushed the update-performance branch from 58defd5 to 3afbe36 Compare March 17, 2026 20:09

rami3l approved these changes Mar 17, 2026

View reviewed changes

Conversation

FranciscoTGouveia commented Mar 15, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rami3l Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rami3l Mar 15, 2026 •

edited

Loading