Sovereign Tech Fellowship for Rust maintenance (June-July 2026 report) | Kobzol’s blog

For the past few years, I was sponsored by Futurewei to work on upstream Rust. It was great to have the freedom to work on anything I wanted in Rust, be it new features, performance optimizations, bot/tooling/CI improvements or even non-technical work, such as mentoring, governance, surveys or preparing Rust talks. Alas, nothing lasts forever, and my open source funding ended this February.

While I did not have much time for Rust during the following months anyway, I have applied for the Sovereign Tech Fellowship grant in the meantime, and I was very lucky to actually get into this year’s cohort of funded open source maintainers! And what is even better is that another Rust maintainer, Denis Cornehl, who maintains docs.rs, got into the same cohort too.

My funding started in June, and should last for a year, which is awesome, because now I can again fully focus on working on Rust. I thought that I would post periodic (bi-monthly) updates about the upstream Rust work that I do, similar to the one I shared earlier this year. Every two months, I’ll try to pick a few highlights, summarize the rest of interesting stuff that I worked on, and also provide contribution statistics and a raw list of opened PRs.

This post details my open source Rust work done in June and July 2026.

Compile time improvements

After a relatively long time, I spent some effort on optimizing Rust compile times, which was fun, as this is one of my favourite activities. I approached it from a couple of angles.

Optimizing Cargo

During my bors talk at RustWeek 2026, I noted that the compile times of tests in bors are pretty terrible. Recently, I finally spent some time analyzing the causes of it. I thought that I would be working on removing bottlenecks from the compiler (and I still plan to do that!), but by profiling, I actually found some bottlenecks in Cargo, so I took a detour and spent a few days to try to make it faster.

I sent a couple of pull requests to Cargo that removed unnecessary cloning (#17167, #17176, #17178), switched to a better data structure (#17180) or pre-allocated memory (#17177). With the exception of #17167, the perf. effect of those PRs was very small.

What helped much more was replacing the hashing algorithm used by hashmaps and sets in Cargo. Most of its associative data structures were using the default hasher from the standard library, which is quite slow. I switched all such data structures to use FxHash, the hashing algorithm used by the Rust compiler, in #17169. This resulted in ~8-10% wall-time improvement for no-op Cargo invocations on Zed, which was quite cool.

Finally, as discussed later in this post, I also configured Rust’s CI to optimize Cargo with PGO in #159149.

The changes I made were mostly only micro-optimizations, rather than algorithmic changes, which typically means that you won’t get that much speedup. That being said, the “final” results are still quite nice. I took nightly Cargo from 1st of July, which is a day before I started working on the optimizations, and compared it with<br>5a8cd237d4fad99d862aed51fab8cb5345c970131, which is the merge commit of the PR that added PGO to Cargo. I am not aware of other performance work happening in Cargo in the meantime and the Cargo submodule was since synced to rust-lang/rust, so this benchmark should mostly correspond to the improvements that I made.

I tested a no-op (also called “fresh”, meaning that all sources were up-to-date and the Rust compiler was not invoked) cargo test --no-run execution on bors:

/pr/pe/ru/bors [benchmark]$ hyperfine "cargo +nightly-2026-07-01 test --no-run" "cargo +5a8cd237d4fad99d862aed51fab8cb5345c97013 test --no-run" --runs 50<br>Benchmark 1: cargo +nightly-2026-07-01 test --no-run<br>Time (mean ± σ): 227.6 ms ± 3.8 ms [User: 141.2 ms, System: 90.3 ms]<br>Range (min … max): 222.1 ms … 239.2 ms 50 runs

Benchmark 2: cargo +5a8cd237d4fad99d862aed51fab8cb5345c97013 test --no-run<br>Time (mean ± σ): 184.3 ms ± 6.6 ms [User: 104.2 ms, System: 84.3 ms]<br>Range (min … max): 178.4 ms … 216.9 ms 50 runs

Summary<br>cargo +5a8cd237d4fad99d862aed51fab8cb5345c97013 test --no-run ran<br>1.24 ± 0.05 times faster than cargo +nightly-2026-07-01 test --no-run

I consistently saw a 20% wall-time improvement on bors. On Zed, I measured a similar 18% wall-time win (fresh cargo check time went from 1100ms to 930ms).

Since I was using the “Performance Optimizer Observation Platform” (poop) a lot while benchmarking Cargo during my optimization experiments, here are its results on bors:

poop "cargo +nightly-2026-07-01 test --no-run" "cargo +5a8cd237d4fad99d862aed51fab8cb5345c97013 test --no-run"

Benchmark 1 (22 runs): cargo +nightly-2026-07-01 test --no-run<br>measurement mean ± σ min … max outliers delta<br>wall_time 228ms ± 12.8ms 219ms … 271ms 3 (14%) 0%<br>peak_rss 106MB ± 402KB 106MB … 107MB 0 ( 0%) 0%<br>cpu_cycles 559M ± 22.0M 540M … 636M 2 ( 9%) 0%<br>instructions 1.01G ±...