Overall progress

The measurements for the period 2025-12-03 to 2026-07-29 can be seen here.

The mean wall-time reduction was a healthy 5.59%. Around half of this was due to some huge recent improvements in rustdoc, which saw a mean wall-time reduction of 37.92%! With the rustdoc changes excluded, the mean wall-time change was 2.90%, which is still a good result. There were also some major improvements to the speed of Clippy, which isn’t currently measured by rustc-perf on CI. (More about that below.)

rustdoc

#159623, #159721, #159779, #159854: In these PRs, Noah Lev greatly reduced the amount of work done when processing impls. I won’t pretend to understand what he did in any more detail than that (see here for some background) but I do know it resulted in many double- and single-digit percentage reductions in wall-times. Guillaume Gomez said “all of that because someone encountered a weird bug when using rustdoc”.

#159091: In this PR Jakub Beránek added rustdoc benchmarks to the PGO training set, which lets rustdoc benefit more from PGO. This gave a mean 2.85% reduction in wall-time across all the rustdoc benchmarks, with the largest reduction exceeding 6%. PGO is fiddly to set up but it can really make a difference, and the training set matters.

#157179: In this PR I changed the way rustdoc sorts impls. Previously it was sorting long generated HTML strings containing impl names; now it uses a much shorter text representation of the impl name as the sort key. This reduced instruction counts across multiple benchmarks, in the best case by more than 6%.

The combined effect of these improvements can be seen in the following graph of the relative wall-time of all the rustdoc benchmarks.

That’s a 28% reduction!

#2515: On a different note, in this PR Jakub enabled rustdoc-json benchmarking on rustc-perf. This will be helpful for the speed of tools that use rustdoc’s JSON output, such as cargo-semver-checks.

Clippy

#17124, #17132: In these two PRs, xmakro made some huge speed-ups to Clippy. Clippy consists of hundreds of separate lints, each of which can implement one or more of a few dozen visitor methods: check_item, check_stmt, check_expr, etc. Clippy traverses the AST and HIR and for each node it calls the appropriate check_foo method for every lint on that node. Each call is a virtual dispatch. Critically, most of these calls are no-ops because most lints only implement a small number of check_foo methods (often just one). In these PRs, xmakro found a way to combine the passes so that the empty check_foo methods (i.e. the vast majority) are not called.

Around the same time I was investigating the exact same issue, and I came up with a slightly different solution in #157762. My solution was functionally equivalent but the code changes were less elegant and more invasive than xmakro’s. The PR didn’t merge, but I was able to get more detailed measurements: in most cases this reduced Clippy’s runtime by 10-30%! Branch mispredictions were reduced by 20-80% on real-world examples and by 97% on one stress test. The cost of virtual dispatch adds up if you do it a lot.

Even though I’ve been working on Rust compiler performance for ten years, this was the first time I tried to optimize Clippy. I found a major performance problem and fixed it, only to find someone else had beaten me to it by a few days. I’m not sad because the better solution was merged, but I am still surprised—what are the chances of that?

Incremental compilation

We saw a number of minor improvements to incremental compilation.

#153122: In this PR Zalathar improved how incremental compilation promotes disk-cached values into memory, reducing instruction counts on many benchmarks, in the best case by 6%.

#153521: This PR was another tweak to incremental compilation by Zalathar, reducing instruction counts on many benchmarks, in the best cases by more than 2%.

#154304: In this PR zetanumbers adjusted how the typeck query works, for instruction count reductions across multiple benchmarks, in the best case by 6%.

#157781: In this PR xmakro tweaked incremental compilation for instruction count reductions across many benchmarks, in the best case by 5%.

#158794: In this PR xmakro improved dep graph read deduplication for instruction count reductions across multiple benchmarks, in the best case by 10%.

#159115: In this PR xmakro again improved dep graph read deduplication for instruction count reductions across many benchmarks, in the best case by 6%.

New trait solver

A lot of work is underway to get the new trait solver ready for release. This includes performance work. There is a lot going on and I’m not aware of most of it, but this Zulip thread is a good place to read if you are interested in learning more or helping.

The following image shows the progress on one of the new solver benchmarks.

That’s right: the wall-time on this benchmark has dropped from 27 seconds to less than one second over the past three months.

#160005: I will mention this one because it’s fun. lcnr pointed at a couple of crates where the new trait solver was causing very large slowdowns. I used Cachegrind to profile rustc compiling them and found that almost half the time was spent in memcpy! This is very unusual, but when it happens DHAT’s copy profiling is unbelievably useful. There was a hot vector with an element type that was 136 bytes in size. LLVM uses memcpy (instead of generated instructions) to move around any value with a size greater than 128 bytes. In this PR I (a) avoided 2/3 of the moves, and (b) shrank the type down to 104 bytes so that memcpy wasn’t used for the remaining moves. This reduced wall-times for the two worst crates by 40%.

New contributors

There has been a welcome uptick in the amount of performance work being done recently and I want to highlight two newcomers. The first is xmakro, who was mentioned four times above. The second is arya dradjica, the creator of Krabby, an experimental Rust compiler focused on speed. arya is now getting financial support to work on both Krabby and rustc. arya’s rustc work is currently focused on macro expansion, where she has already made a few small performance improvements (e.g. #158976, #158974, and #158577) and she has ideas for many more. Check out her recent RustWeek talk if you want to know how much she loves optimizing things. (Spoiler: a lot.)

LLMs

They’re getting a lot of attention, aren’t they? Anyway, enough about that.

AST

#158942: In this PR I shrank the size of some AST nodes by removing a field. The removed data, when needed, is now stored temporarily to the side. This gave mostly sub-1% reductions in instruction counts.

#158720: The previous PR paved the way for this PR, in which I shrank the size of AST expression nodes from 72 bytes to 64 bytes. (Small enough to fit in a cache line.) Expressions are by far the most common AST node kind, and this change reduced wall-time on a small number of AST-heavy benchmarks, some by more than 10%. Cache miss rates on those same benchmarks fell by as much as 29%. I remember a few years ago when AST expression nodes were 104 bytes. Good performance often comes from chip, chip, chipping away at things over the long term.

#159266: In this PR I overhauled the AST representation of attributes. It was mostly intended to be a code cleanup, though it did result in some sub-1% reductions in instruction counts.

Miscellaneous

#155678: In this PR aerooneqq merged several HIR-level queries into one, reducing instruction counts on many benchmarks, in the best cases by almost 3%.

Performance triage

I want to recognize the people who take turns at the weekly performance triage. This involves looking at all the merged PRs from the past week that affected performance (for both good and bad) and gathering additional information to help isolate and fix the performance regressions. It’s an unglamorous, semi-automated task that might seem like it could be fully automated, but I think it’s important that humans are involved.

Why? Because the benchmark suite is large and complicated, the measurements aren’t always precise, and human involvement can be persuasive. It’s one thing for a PR author to receive a message from a bot saying “this PR caused nine benchmarks to regress”. It’s a very different thing to receive a message from a human with domain expertise saying “you can ignore the first four because those benchmarks have been noisy lately; you can ignore the next three because the regressions are so small that they are insignificant; but you should look at the last two because they’re real and significant and might be caused by $REASON and do you have ideas on how to ameliorate that?”

So, thank you to the current triage crew: Mark Rousskov, Jonathan Brouwer, Matyáš Racek, and Jakub Beránek. (The 50% Czech representation is visible via diacritics.) And thank you also to the triage alumni: Felix Klock, Dylan MacKenzie, and Ryan Levick.

One last thing

Some personal news: I recently quit my job at VectorWare. Nothing dramatic; it just wasn’t the right fit for me. I am now pursuing opportunities to return to paid work on the Rust compiler. Wish me luck!

Compiler improvements

#142095: The compiler has a data structure called VecCache which is a key-value store used with keys that are densely-numbered IDs, such as CrateNum or LocalDefId. It’s a segmented vector with increasingly large buckets added as it grows. In this PR Josh Triplett optimized the common case when the key is in the first segment, which holds 4096 entries. This gave icount reductions across many benchmark runs, beyond 4% in the best cases.

#148040: In this PR Ben Kimock added a fast path for lowering trivial consts. This reduced compile times for the libc crate by 5-15%! It’s unusual to see a change that affects a single real-world crate so much, across all compilation scenarios: debug and release, incremental and non-incremental. This is a great result. At the time of writing, libc is the #12 mostly popular crate on crates.io as measured by “recent downloads”, and #7 as measured by “all-time downloads”. This change also reduced icounts for a few other benchmarks by up to 10%.

#147293: In the query system there was a value computed on a hot path that was only used within a debug! call. In this PR I avoided doing that computation unless necessary, which gave icount reductions across many benchmark results, more than 3% in the best case. This was such a classic micro-optimization that I added it as an example to the Logging and Debugging chapter of the The Rust Performance Book.

#148706: In this PR dianne optimized the handling of temporary scopes. This reduced icounts on a number of benchmarks, 3% in the best case. It also reduced peak memory usage on some of the secondary benchmarks containing very large literals, by 5% in the best cases.

#143684: In this PR Nikita Popov upgraded the LLVM version used by the compiler to LLVM 21. In recent years every LLVM update has improved the speed of the Rust compiler. In this case the mean icount reduction across all benchmark results was an excellent 1.70%, and the mean cycle count reduction was 0.90%, but the mean wall-time saw an increase of 0.26%. Wall-time is the true metric, because it’s what users perceive, though it has high variance. icounts and cycles usually correlate well to wall-time, especially on large changes like this that affect many benchmarks, though this case is a counter-example. I’m not quite sure what to make of it; I don’t know whether the wall-time results on the test machine are representative.

#148789: In this PR Mara Bos reimplemented format_args!() and fmt::Arguments to be more space-efficient. This gave lots of small icount wins, and a couple of enormous (30-38%) wins for the large-workspace stress test. Mara wrote about this on Mastodon. She also has written about prior work on formatting on her blog and in this tracking issue. Lots of great reading there for people who love nitty-gritty optimization details, including nice diagrams of how data structures are laid out in memory.

Proc macro wins in Bevy

In June I added a new compiler flag -Zmacro-stats that measures how much code is generated by macros. I wrote previously about how I used it to optimize #[derive(Arbitrary)] from the arbitrary crate used for fuzzing.

I also used it to streamline the code generated by #[derive(Reflect)] in Bevy. This derive is used to implement reflection on many types and it produced a lot of code. For example, the bevy_ui crate was around 16,000 lines and 563,000 bytes of source code. The code generated by #[derive(Reflect)] for types within that crate was around 27,000 lines and 1,544,000 bytes. Macro expansion almost quadrupled the size of the code, mostly because of this one macro!

The code generated by #[derive(Reflect)] had a lot of redundancies. I made PRs to remove unnecessary calls, duplicate type bounds (and a follow-up), const _ blocks, closures, arguments, trait bounds, attributes, impls, and finally I factored out some repetition.

After doing this I measured the bevy_window crate. The size of the code generated by #[derive(Reflect)] was reduced by 39%, which reduced cargo check wall-time for that crate by 16%, and peak memory usage by 5%. And there are likely similar improvements across many other crates within Bevy, as well as programs that use #[derive(Reflect)] themselves.

It’s understandable that the generated code was suboptimal. Proc macros aren’t easy to write; there was previously no easy way to measure the size of the generated code; and the generated code was considered good enough because (a) it worked, and (b) the compiler would effectively optimize away all the redundancies. But in general it is more efficient to optimize away redundancies at the generation point, where context-specific and domain-specific information is available, rather than relying on sophisticated optimization machinery further down the compilation pipeline that has to reconstruct information. And it’s just less code to parse and represent in memory.

rustdoc-json

At RustWeek 2025 I had a conversation with Predrag Gruevski about rustdoc-json (invoked with the --output-format=json flag) and its effects on the performance of cargo-semver-checks. I spent some time looking into it and found one nice win.

#142335: In this PR I reduced the number of allocations done by rustdoc-json. This gave wall-time reductions of up to 10% and peak memory usage reductions of up to 8%.

I also tried various other things to improve rustdoc-json’s speed, without much success. JSON is simple and easy to parse, and rustdoc-json’s schema for representing Rust code is easy for humans to read. These features are great for newcomers and people who want to experiment. It also means the JSON output is space-inefficient, which limits the performance of heavy-duty tools like cargo-semver-checks that are designed for large codebases. There are some obvious space optimizations that could be applied to the JSON schema, like shortening field names, omitting fields with default values, and interning repeated strings. But these all affect its readability and flexibility.

The right solution here is probably to introduce a performance-oriented second format for the heavy-duty users. #142642 is a draft attempt at this. Hopefully progress can be made here in the future.

Faster compilation of large API crates

Josh Triplett introduced a new experimental flag, -Zhint-mostly-unused, which can give big compile time wins for people using small fractions of very large crates. This is typically the case for certain large API crates, such as windows, rustix, and aws-sdk-ec2. Read about it here.

Faster Rust builds on Mac

Did you know that macOS has a secret setting that can make Rust builds faster? No joke!

General progress

Progress since May must be split into two parts, because in July we changed the machine on which the measurements are done.

The first period (2025-05-20 to 2025-06-30) was on the old machine. The second period (2025-07-01 to 2025-12-03) was on the new machine.

The mean wall-time changes were moderate improvements (-3.19% and -2.65%). The mean peak memory usage changes were a wash (+1.18% and -1.50%). The mean binary size changes were small increases (0.45% and 2.56%).

It’s good that wall-times went down overall, even if the other metrics were mixed. There is a slow but steady stream of bug fixes and new features to the compiler, which often hurt performance. In the absence of active performance work the natural tendency for a compiler is to get slower, so I view even small improvements as a win.

The new machine reduced wall-times by about 20%. It’s worth upgrading your hardware, if you can!

This job is not a “work full-time on the Rust compiler” position like my last one. But it will involve a lot of open source work, some Rust compiler work, and I will continue to be a Rust compiler team member and maintainer. I will also get to learn about GPU programming, a new area for me. Indeed, my main accomplishment in my first week was to write Rust code that uses the GPU to render the company logo.

Back in July I wrote that I was looking for a new job. There has been some public speculation about the lack of a follow-up post and what that meant. Was I having trouble finding a new job? If so, what does that mean for Rust? What does it suggest for tech hiring in general? And so on. Fortunately, this speculation was largely ill-informed, for two reasons.

First, I made the decision to join VectorWare a few weeks ago, but it took some time for the paperwork to be completed and things organised enough for a public announcement.

Second, I was lucky enough to be contacted by a lot of people who were interested in possibly hiring me. I won’t try to draw any conclusions from this about finding Rust jobs in general, because I am fortunate to have an atypical level of experience and prominence when it comes to Rust. However, it did demonstrate that Rust is being used in an impressive range of areas.

Specifically, Rust is being used for: operating systems, compilers/interpreters, wasm, GPU programming, quantum computing, databases, data analytics, networking/cloud/server, medical, space, defence, automotive, embedded, security software, malware detection, search, formal methods, CAD, devtools, collaborative software, device management, real-time systems, prediction markets, biotech, identity verification, document generation, hardware simulation, and software modernization. (And also generative AI, cryptocurrencies/blockchain, and algorithmic trading; I did receive a few messages relating to these despite saying I didn’t want to work on them.) Rust is being used by huge companies, tiny startups, and everything between.

This is a really encouraging sign! I knew Rust was doing well, but I didn’t know it was doing this well.

Searching for a new job is never a fun or easy exercise, but this time it was about as good as it gets. Many thanks to everyone who helped: those who contacted me with interest, those who passed news of my availability along, and those who pointed me at Rust opportunities they were aware of. I appreciate it. I can now get to work on the new stuff and go back to pretending that LinkedIn doesn’t exist.

The problem

Isaac Asimov reportedly said: the most exciting phrase to hear in science… is not “Eureka” but “that’s funny…”

I noticed something recently while looking at the output of cargo build --timings on Mac: build scripts took a strangely long time to execute. Consider the following output from compiling wild on my 2019 MacBook Pro.

Time is on the x-axis. Each blue/purple bar is a single invocation of the compiler. (This image shows only part of the output. The full compilation has over 100 crates.) Each orange bar measures the time taken to execute a build script. The orange bars are quite long!

Build scripts let you do custom tasks that fall outside the normal Cargo workflow. Sometimes they are expected to be slow, such as when invoking a C compiler to build a library. But often they are trivial. A common case is to run rustc --version to see what version of the compiler is installed and then adjust some configuration detail accordingly.

All the build scripts shown in this output are simple ones that should be very quick to run, and that’s what I saw when I measured on Linux. So why were they taking between 0.48 and 3.88 seconds on Mac? And why was each successive one slower than the previous?

I tried running a couple of these build scripts directly instead of via Cargo. They were much faster that way, e.g. 75ms vs. 300ms. Weird. At first I suspected that Cargo was mismeasuring the build script executions somehow. I looked at the relevant code in Cargo but it was pretty straightforward and seemed unlikely to be hiding a problem.

The explanation

Before digging further I asked on Zulip if this behaviour was familiar to anyone. Weihang Lo suggested it might be caused by code-signing verification or some other security check.

Wait, what? This was not the answer I was expecting, but it was correct. macOS has an antivirus feature called XProtect.

XProtect checks for known malicious content whenever:

• An app is first launched
• An app has been changed (in the file system)
• XProtect signatures are updated

In other words, the OS scans every executable for malware on the first run. This makes sense for executables downloaded from the internet. It’s arguably less sensible for executables you compiled yourself. Indeed, build scripts are the worst possible case for this kind of check, performance-wise, because each build script executable is typically run exactly once.

(XProtect is closely related to another security feature called Gatekeeper. As I understand it, Gatekeeper verifies signed code while XProtect does generic malware scans. Note that people often use the name “Gatekeeper” when referring to all of these activities.)

The workaround

You can avoid these scans by adding Terminal (or any alternative terminal app you are using, such as iTerm) as a “developer tool” in System Settings. See these docs for details. Note: as the docs say, you will likely need to restart Terminal for the change to take effect. But if you want to undo the change, you might need to reboot the machine for the change to take effect.

This is the “secret setting” I mentioned at the start of this post. Searching around, I found only a few online mentions of it.

• A blog post.
• A users.rust-lang.org post.
• A Hacker News comment.
• The cargo-nextest docs, which cite the Hacker News comment.
• The Zed docs, which cite the cargo-nextest docs.
• Corrode’s Tips for Faster Rust Compile Times, which cites the cargo-nextest docs and the Zed docs! (This post is an excellent and comprehensive collection of tips for speeding up Rust compilation, by the way.)
• A rust-lang Zulip thread.

Please note that if you do this you are disabling an OS security feature. You should not do it unless you are comfortable with the potential speed/security trade-off.

The benefits: cargo build, cargo check

The following image replicates the cargo build --timings partial output from above alongside the corresponding partial output from a run with XProtect disabled.

A huge difference! Those orange bars are now tiny. The build scripts are taking around 0.06 to 0.14 seconds each on my old MacBook Pro.

This definitely has the potential to speed up full builds of various Rust projects. In this case, the original wild build took 25.9s and the new one took 25.0s. I didn’t do careful measurements to see if those numbers were consistent. (Don’t read too much into the times taken to compile individual crates; the scheduling between the two runs is very different.)

The exact effect will depend heavily on a project’s dependency graph and the characteristics of your machine, but if build script execution is on the critical path it will certainly have an effect.

Great! But maybe you don’t actually run build scripts all that often. Most of the time you’re just rebuilding your own code, not third-party dependencies, other than after the occasional cargo clean, right? Well…

The benefits: cargo run

If your project is an executable, you’ll be paying the XProtect cost every single time you rebuild and rerun. It’s extra time on every edit-compile-run cycle. Yuk.

The benefits: cargo test

Disabling XProtect also helps for test binaries. In fact, this is the area with the potential for the biggest speedups, because some test setups involve many small binaries. For example, every integration test gets its own binary. And every pre-2024-edition doctest gets its own binary! And the cargo-nextest folks clearly noticed it.

The Rust compiler itself provides a particularly compelling example. Its biggest test suite is called tests/ui/ and involves running almost 4,000 individual executables, most of them tiny. Mads Marquart found that disabling XProtect reduced the runtime of this test suite from 9m42s to 3m33s! Incredible.

The benefits: other languages

I haven’t tested this, but developers using other compiled languages will presumably benefit similarly, so long as development involves frequent compilation and execution of binaries.

Spreading the joy

The status quo is that this behaviour is documented in a few obscure places and 99%+ of Mac users are unaware. Fortunately, Mads has a draft PR for Cargo that detects if XProtect is enabled and issues a warning to the user explaining its impact and how to disable it. (There is apparently no programmatic way to disable XProtect in the terminal and we wouldn’t want to do that anyway; the user should be required to make an active choice.)

The PR is worth a look because it has a precise description of the situation, one that goes into more detail than I have here. Also, it answers a question posed much earlier in this post: in the original cargo build --timings output, why was each successive build script slower than the previous? The PR has the answer:

the XprotectService daemon runs in a single thread, so if you try to launch 10 new binaries at once, the slowdown will be more than a second.

On my old MacBook Pro, which has eight cores, it’s much more than a second. Going back to my original cargo build --timings run, the final build script took 3.88s to run. Its execution overlapped with that of most of the previous build scripts. Most of that 3.88s is actually spent waiting for the daemon. Good grief.

There will need to be careful discussion and review of how the warning is presented to the user, given that it’s about disabling an OS security feature. But I am happy there is a clear path forward to get this knowledge out of “deep lore” territory and into the purview of normal users. In the meantime, if you are a Mac user you could consider disabling XProtect in the terminal and get the speed benefits immediately.

You can update with the command cargo update -p arbitrary -p derive_arbitrary.

Fuzzing with Arbitrary

The Arbitrary crate is very useful when fuzz testing Rust code. From the README:

The Arbitrary crate lets you construct arbitrary instances of a type.

This crate is primarily intended to be combined with a fuzzer like libFuzzer and cargo-fuzz or AFL, and to help you turn the raw, untyped byte buffers that they produce into well-typed, valid, structured values. This allows you to combine structure-aware test case generation with coverage-guided, mutation-based fuzzers.

In other words, it defines a trait Arbitrary that can be used to convert a stream of randomized bytes into valid values. Like many good Rust libraries it uses proc macros to make user’s lives easy: you can just stick #[derive(Arbitrary)] on a type and it will automatically generate the conversion code for you.

Code size

I was recently using the Rust compiler’s new -Zmacro-stats option on a project that used #[derive(Arbitrary)] and saw that the proc macro was generating a lot of code. Even for a simple struct like struct S(u32, u32) it would generate more than 100 lines of code. In a large project containing many types marked with #[derive(Arbitrary)], that much code can add up and cause a lot of work for the compiler.

I used cargo expand to inspect the generated code. Annoyingly, only a fraction of it code was doing the actual conversion of random bytes to valid values. The rest involved a per-type counter that protects against an edge case that can cause infinite recursion on recursive types.

Improvements

I made three small improvements.

#227: In this PR I marked the per-type counter as const, which enables a more efficient thread local implementation that can avoid lazy initialization and does not need to track any additional state.

#228: The per-type counter was generated for every type marked with #[derive(Arbitrary)], even ones that aren’t recursive. Why? It’s surprisingly hard for a proc macro to tell if a type is recursive. Proc macros work entirely at the syntactic level, without access to type information. At that level, any field might lead to type recursion. (Even builtin types like u32? Yes, because it’s possible to define your own type called u32. Sigh.) However, there is one family of types that can never be recursive: fieldless enums like enum { A, B }. In this PR I removed the per-type counter and the corresponding code for all such types. For an artificial stress test containing 1,000 fieldless enums, this change reduced compile times by 75%.

#229: The code updating the per-type counter was somewhat repetitive. In this PR I factored out the repetitiveness, in a way that shouldn’t affect runtime speed. For another artificial stress test containing 1,000 simple structs, the change reduced compile times by 30-40%.

On a real-world project using Arbitrary these changes reduced incremental rebuilds from 4.0s to 3.8s, a ~5% reduction. It’s possible that the changes might also increase fuzzing speed, though I haven’t measured that and any effect is probably small.

You should update, like, now

These are not enormous wins, but hey, updating Rust crates is really easy. You should update arbitrary and derive_arbitrary to version 1.4.2, right now. Check Cargo.lock to make sure you did it right.

Happy fuzzing!

For the past 3.75 years I have been fortunate to work on Futurewei’s Rust team, where I had enormous freedom to “make Rust better” however I see fit. It has been the highlight of my career and I am grateful to Sid Askary and other Futurewei folks that helped make it happen.

Unfortunately, this job is going away soon; the team is being shrunk due to budget cuts. I don’t have insight into the detailed reasoning, but I suspect it mostly comes down to two things: (a) international politics and economics are in upheaval, and (b) AI is sucking up a lot of money and attention in the tech world, leaving less for everything else.

I would love to find a position that lets me continue to work on Rust in this fashion. Rust is an incredible project and technology. It needs and deserves to have people who are paid full-time to maintain it, and I believe I am a good person to do this.

Some numbers

It’s hard to quantify impact, but let’s give it a try. All numbers are correct at the time of writing.

First, let’s start with commits to the rust-lang/rust repository.

• git log says I have made 3,375 commits.
• 560 were from 2016-2020, during my time at Mozilla, where I found ways to contribute to Rust part-time despite not being on the Rust team.
• 2,815 were since I joined the Futurewei team in late 2021.
• This puts me at #16 on the all-time contributors list, which goes back to 2010. It’s #14 if you exclude the #1 and #2 entries which are for a bot and a person that do a large number of merge commits.
• The contributors list includes people who haven’t been active for years. If we restrict it to the last two I am at #6, or #4 after excluding merge commits. (This time window can be selected via a drop-down menu at the top right of the contributors list, though it doesn’t produce a usable link.)

Next, let’s expand consideration to GitHub contributions, which includes (non-merge?) commits and also things like issue creation, reviews, and discussions.

• I am currently the #16 contributor, with 4013 contributions, or #15 if we exclude @bors the bot.
• I don’t know where I ranked when I started at Futurewei, but I would estimate slightly outside the top 100.
• My contribution rate has ticked up over time, and I have been in the top five human contributors to several Rust releases.

Commits and contributions are imperfect measures of impact, for sure. But when the numbers get high enough, I think they provide a decent signal. The other names at the top of these lists are all highly valuable and prolific project members.

Areas of expertise

I was a “compiler contributor” for a long time, which was the designation used for the second tier of contributors, in comparison to the first tier in the “compiler team”.

Last year things were reorganised and I am now a “compiler team member” (“someone who contributes regularly”) and also a “maintainer” (“not only a regular contributor, but are actively helping to shape the direction of the team or some part of the compiler (or multiple parts)”)

I am a member of the primary reviewers group.

I am also a member of the compiler performance working area and the parallel rustc working area.

In terms of the compiler codebase:

• The compiler is over 700,000 lines of code, in the compiler/ directory of the Rust repository.
• I have laid eyes on almost every file in compiler/.
• I have committed changes to 75 of the 77 crates in compiler/.

Some compiler areas where I have particular depth of expertise include the following.

• Compiler performance, profiling and benchmarking
• Lexing and parsing
• Token/AST representation and processing, including macro expansion
• Builtin macro code generation
• Compiler error generation
• Dataflow analysis structure
• CGU splitting

I have also made major contributions to rustc-perf, smaller contributions to rustdoc, clippy, rustfmt, and cargo, and a handful of contributions to external projects like quote, Bevy, cargo-fuzz, cargo-llvm-lines, The Little Book of Rust Macros, thin-vec, rust-smallvec, and c2rust.

Specific contributions

In the Rust community I’m best known for working on compiler performance, and in the past 3.75 years I’ve done a lot of work there. Some highlights:

• I oversaw the compiler performance roadmap in 2022.
• I analyzed the compiler’s performance on the most popular 1000 crates, and made a number of speedups as a result.
• I overhauled declarative macro expansion, giving big speed wins and also making the code simpler and more maintainable.
• I optimized the code generated for derived traits such as Debug, reducing compile times.
• I implemented a new flag -Zmacro-stats to measure proc macro code size and then shrank the size of Bevy’s #[derive(Reflect)] code. This reduced the cargo check time for the bevy_ui crate by 16%.
• I helped with the rustc-perf benchmark suite updates in 2022 and 2025.
• I overhauled Cachegrind’s annotation tools to make them more useful for profiling the Rust compiler and other complex programs.
• I continued writing my long-running “How to speed up the Rust compiler” blog series, with another dozen posts.
• There are far too many individual PRs to mention, but three of my favourites were: ChunkedBitSet and the removal of HybridBitSet; deep `fast_reject (with @lcnr); and a surprisingly massive rustdoc speedup.

I also branched out and did a lot of non-performance work. A lot of this can be classified as “maintainability” or “cleanup” or “refactoring” or “tech debt removal”. I have a knack for it and in a codebase as large and old as the Rust compiler it is always valuable. Some examples:

• I overhauled the internal APIs for generating compiler errors, which are used all over the compiler and were a mess, via 30+ PRs and hundreds of commits. My favourite review comment was this one:

  Thanks for finally making emit consume. You broke the “add 1 to this counter if you tried” situation.

  I.e. I fixed a problem that multiple other people had previously tried and failed to fix. It only took a PR with 14 commits that touched 112 files.

• I greatly simplified the structure of the dataflow analysis passes.
• I removed an awful internal design detail whereby AST nodes could be embedded in tokens. I completed this three years after I first tried, on the third attempt, after a great number of preliminary cleanups.
• I removed save-analysis and compiler plugins, two compiler features that had been deprecated for years but needed someone to push through their removal. These removals then enabled various subsequent simplifications.
• I overhauled and simplified how codegen unit splitting works in the compiler backend.
• I turned on use item formatting within the compiler, a surprisingly controversial change. The PR modified 1,867 files, which is my biggest single PR. I am very happy to no longer have to think how to format use items.
• I simplified compiler/rustdoc startup in a few ways, e.g. one example is here.
• I fixed a ton of inconsistencies in operator representation in tokens and the AST.
• I fixed a lot of places where the empty symbol was misleading used to mean “no symbol”, fixing some bugs along the way. (This is Rust, not C, we have the Option type.)
• I got rid of the ancient P type in the AST. It was a smart pointer type that predated Rust 1.0, and I replaced it with Box.

If I run the following command that summarizes my changes on the repository:

git log --author="Nicholas Nethercote" -p | diffstat

the output is this:

8759 files changed, 145338 insertions(+), 152183 deletions(-)

Negative lines of code! Nice. Fittingly, by far the most common first word in my commit messages is “Remove”, used on 752 of 3,375 commits.

Other activities

Most of my work is around code, but I have also done some other things over the past 3.75 years.

• I gave talks at RustNL 2023, GOSIM 2023, and GOSIM 2024.
• I attended RustConf 2022 and RustWeek 2025 and the co-located unconferences for project members. RustWeek 2025 was especially good, I met and reconnected with a lot of people and I returned home feeling newly energized. (Which makes my losing my job shortly afterward all the more disappointing.)
• I have done a small amount of Rust performance consulting work for ISRG and OpenAI.
• I maintained The Rust Performance Book.
• I did all this while working 100% remotely in Melbourne, Australia, something I’ve done since 2009, sometimes as a contractor, sometimes as an employee.

On the job market

In short: I do a lot of work on Rust. I think it’s valuable. I’d love to be able to keep doing it. If you know of any way that could happen, please get in touch.

I have worked in the industry for almost twenty years. I have worked for Mozilla and Apple. I have a PhD in Valgrind and other publications. I co-won the Most Influential PLDI Paper Award in 2017.

If I can’t find a job that involves me working on Rust, I would like to find a job that uses Rust for interesting ends, preferably in ways that are open source.

I am not interested in any of the following:

• blockchain/cryptocurrencies
• generative AI
• algorithmic trading
• relocating from Melbourne

My contact details and other basic information is here. My LinkedIn profile is here. Thank you for reading this far!

Proc macro costs

There are several ways proc macros affect compile times.

1. The time to compile the proc macro crate itself.
2. The time to compile all crates that the proc macro crate depends on, often including proc-macro2, syn and quote.
3. The time to run the proc macro invocations.
4. The time to compile the code generated by the proc macro invocations.

For costs 1 and 2, “compile” means full compilation including code generation, even when you are running cargo check. This is one reason why cargo check output includes a mix of “Checking” and “Compiling” lines. (The other reason for “Compiling” lines is crates with build scripts, and crates that build scripts depend on.)

watt is an approach to avoid costs 1 and 2. This is reasonable, but those costs usually occur only on clean builds. Costs 3 and 4 will occur on clean builds and also on many rebuilds. I am particularly interested in cost 4, because I think it might be underappreciated. That is what this post is about.

Proc macros are trivial to invoke, but it’s harder to know how much code they generate. You can use cargo-expand to inspect the code after macro expansion has finished. This can be useful, but lots of people don’t know about it, and it doesn’t scale in a large codebase.

For example, I recently looked at a large project that had around 100,000 lines of code and used proc macros heavily. After macro expansion, the code size more than tripled! Once the project authors knew about this they were able to eliminate some proc macros that weren’t important, and replace some heavyweight ones with lightweight ones. After these small changes their compile times dropped by around 20%.

A new tool to help

I recently implemented a new unstable flag for the Rust compiler, -Zmacro-stats, that can help shine a lot on proc macro code size. It is available in Nightly, and there are two basic ways to use it.

If you just want to know about a leaf crate of your project, you can run a command like this:

cargo +nightly rustc -- -Zmacro-stats

and it will print information about the amount of code generated by both proc macros and declarative macros, though the former are usually more notable.

Or, if you want to know about multiple crates of your project, you can run a command like this:

RUSTFLAGS="-Zmacro-stats" cargo +nightly build

What does the output look like? Consider this very simple Rust program called measure_proc_macros:

fn main() {
    println!("yellow bird");
}

#[test]
fn my_test() {
    assert_eq!(1 + 1, 2);
}

Here’s the -Zmacro-stats output, which is printed on stderr:

===============================================================================
MACRO EXPANSION STATS: measure_proc_macros
Macro Name                         Uses    Lines  Avg Lines    Bytes  Avg Bytes
-------------------------------------------------------------------------------
println!                              1        1        1.0       63       63.0
::std::format_args_nl!                1        1        1.0       29       29.0
#[test]                               1        1        1.0        0        0.0
===============================================================================

First, we can see that the println! had one use, and it produced one line of code, which was 63 bytes of text. The byte count is the ultimate measure, but lines of code are also included because that’s a code size measurement that programmers are more used to. The line count is made on code as formatted by the compiler’s internal pretty printer, so it won’t be affected by the formatting of any of the hand-written code.

Next, we can also see an entry for ::std::format_args_nl!. Where did that come from? Well, the println! call expands to code that includes a call to ::std::format_args_nl!, which then gets expanded.

Finally, we see that the #[test] produced zero code. This makes sense, because tests are omitted for normal builds. (I also tried -Zmacro-stats with cargo test and saw that the #[test] invocation generated 24 lines and 802 bytes of code.)

What about proc macros? Let’s try out some derive proc macros by adding this code:

#[derive(Clone, Copy, Debug, Default, PartialEq, Eq, PartialOrd, Ord, Hash)] 
#[derive(derive_more::From, derive_more::Add, derive_more::Constructor)] 
#[derive(serde::Serialize, serde::Deserialize)] 
#[derive(arbitrary::Arbitrary)] 
struct Point { x: i32, y: i32 }

This is a very simple struct with many derives:

• all the builtin derives;
• several builtin-like derives from derive_more;
• serialization and deserialization derives from serde;
• Arbitrary from arbitrary, which is used for fuzzing.

-Zmacro-stats produces this additional output:

===============================================================================
MACRO EXPANSION STATS: measure_proc_macros
Macro Name                         Uses    Lines  Avg Lines    Bytes  Avg Bytes
-------------------------------------------------------------------------------
#[derive(serde::Deserialize)]         1      159      159.0    8_622    8_622.0
#[derive(arbitrary::Arbitrary)]       1       81       81.0    3_679    3_679.0
::std::thread::local_impl::thread_local_inner!
                                      2       34       17.0    1_499      749.5
#[derive(serde::Serialize)]           1       23       23.0    1_002    1_002.0
#[derive(PartialOrd)]                 1       12       12.0      440      440.0
#[derive(Ord)]                        1       11       11.0      333      333.0
#[derive(Debug)]                      1        8        8.0      269      269.0
#[derive(PartialEq)]                  1        9        9.0      255      255.0
#[derive(Hash)]                       1        8        8.0      252      252.0
#[derive(Default)]                    1       10       10.0      246      246.0
#[derive(derive_more::Add)]           1        9        9.0      237      237.0
#[derive(Eq)]                         1        9        9.0      219      219.0
#[derive(derive_more::From)]          1        6        6.0      205      205.0
::std::thread_local!                  2        5        2.5      198       99.0
#[derive(Clone)]                      1        8        8.0      184      184.0
#[derive(derive_more::Constructor)]   1        7        7.0      174      174.0
#[derive(Copy)]                       1        2        2.0       64       64.0
===============================================================================

What have we learned?

• The builtin macros generate small amounts of code, between 2 and 12 lines.
• The derive_more macros are similar. (I tried all of the derives available in that crate, and they all gave similar results.)
• serde::Serialize is a bit bigger at 23 lines, but serde::Deserialize is much bigger at 159 lines.
• arbitrary::Arbitrary is also large, at 81 lines. You can’t tell it from this table, but further inspection revealed that this derive was responsible for the thread_local! and thread_local_inner! invocations, adding another 39 lines, for a total of 120 lines.

All this for a tiny struct with just two fields? Interesting. Let’s try one more example, adding this method code which uses an attribute macro and a declarative macro from the tracing crate:

impl Point {
    #[tracing::instrument]
    fn invert(p: Point) -> Point {
        tracing::debug!("invert the point");
        Point { x: -p.x, y: -p.y }
    }
}

Here’s the output for just that function:

===============================================================================
MACRO EXPANSION STATS: measure_proc_macros
Macro Name                         Uses    Lines  Avg Lines    Bytes  Avg Bytes
-------------------------------------------------------------------------------
::tracing::valueset!                  6       46        7.7    2_053      342.2
::tracing::event!                     2       35       17.5    1_551      775.5
::tracing::span!                      1       31       31.0    1_260    1_260.0
#[tracing::instrument]                1       34       34.0    1_238    1_238.0
::tracing::metadata!                  2       17        8.5    1_138      569.0
::tracing::callsite2!                 2       27       13.5    1_062      531.0
::tracing::level_enabled!             3        6        2.0      434      144.7
::tracing::fieldset!                  6        6        1.0      255       42.5
::tracing::if_log_enabled!            3       10        3.3      231       77.0
tracing::debug!                       1        2        2.0       86       86.0
::tracing_core::identify_callsite!    2        2        1.0       82       41.0
::tracing_core::__macro_support::module_path!
                                      2        2        1.0       42       21.0
module_path!                          2        2        1.0       42       21.0
::tracing::__macro_support::format_args!
                                      1        1        1.0       32       32.0
::tracing_core::__macro_support::file!
                                      2        2        1.0       26       13.0
::tracing::__macro_support::concat!   1        1        1.0       22       22.0
::tracing::__macro_support::file!     1        1        1.0       13       13.0
::tracing::__tracing_stringify!       1        1        1.0       13       13.0
::tracing_core::__macro_support::line!
                                      2        2        1.0       10        5.0
::tracing::__macro_support::line!     1        1        1.0        5        5.0
stringify!                            1        1        1.0        3        3.0
::tracing::__tracing_log!             2        2        1.0        0        0.0
===============================================================================

Wow! I did not expect that. That’s 232 lines of code and 20 auxiliary macros. On this larger example the usefulness of the “average” columns becomes clear.

Using it in practice

I know that -Zmacro-stats can be useful, because I used it on the aforementioned example that saw 20% reductions in compile times. If your codebase is littered with types with a dozen or more derives, give it a shot. If it tells you that a single proc macro macro is responsible for 25% of your post-expansion code, then great! Chase that down. But you could also waste time with it. Shaving off a few lines here and there is unlikely to have an effect. This tool is aimed at large codebases; if your codebase is small this is unlikely to be useful. As always with performance, measure to see if changes are worthwhile. And remember that when talking about compilation, lines of code is a potentially useful proxy measurement, but compile time is the true measurement of interest.

If you do fall into the 25% case, what should you do? It depends greatly on your codebase and how it uses the proc macro(s) in question. But in general, two obvious solutions are (a) avoid the proc macro altogether, or (b) find a cheaper alternative. For example, if serde::Deserialize is a big chunk of your code and you are not relying on any of serde’s advanced features, an alternative like serde-lite or miniserde might be worthwhile.

Finally, this is a very new tool so I’d love to hear from people who try it out, successfully or not, and any ideas for improvement. Thanks!

Benchmarks updated

This update comes hot on the heels of the previous one because Jakub Beránek and I updated most of the “primary” benchmarks in the rustc-perf benchmark suite. These benchmarks are verbatim copies of third-party crates, and we have a policy of updating them every three years to ensure we are measuring code that people are using. This does impact data continuity, though we do have a set of old “stable” benchmarks that never change, plus “secondary” benchmarks (e.g. microbenchmarks) that rarely change.

General Progress

For the period 2025-03-17 to 2025-05-20 you can see the results on the primary metrics here: wall-time, peak memory usage, and binary size. I won’t go in to detail because none of them changed that much. This is a good thing! Because of the benchmarks update we only had 25 benchmarks (mostly secondary benchmarks) measured across the period, instead of the usual 43. My next update will include all the new benchmarks.

One notable improvement

#140561: In this PR, Michael Goulet made a fairly small change to how local variables are gathered by the type checker, making the gathering lazier. This gave an impressive 10%+ reduction in compile times for certain check builds of the cranelift-codegen-0.119.0 benchmark, because it made obligation processing faster. I don’t really understand the effect, but it does make me wonder if there is some kind of custom profiling/logging we could do to identify sub-optimal obligation processing.

Car

In March 2021 I replaced my old car with a Tesla Model 3. At that time the range of electric vehicles available in Australia was meagre and the Model 3 was an easy choice. It has been great. It’s fast, quiet, smooth, and reliable. I love one-pedal driving. I haven’t paid for petrol in four years. I don’t want to ever own an ICE car again.

I charge it from a normal power point in my garage. It takes more than 24 hours to fully charge the battery from empty, but that’s a rare use case for me. Topping up 20-50% overnight is much more common. You can get a special home charger that’s 3.5x faster but I haven’t bothered. My model has an LFP battery which tolerates being charged to 100% regularly, which I like a lot. Charging at home is fantastic, and if you don’t have some kind of off-street parking (garage, carport, or even just a small driveway) that allows this, an EV is a lot less enticing.

I also mostly do city driving. I have used Tesla superchargers on longer drives a few times. This has worked fine, but there aren’t that many of them around and it could be inconvenient if I did lots of long country drives.

Maintenance-wise it’s a dream. Do you know how complicated internal combustion engines are? How many moving parts they have? Electric motors are trivial in comparison. No sparkplugs, belts, chains, or pistons. No transmission! (And no transmission hump in the floor.) I’ve never seen my car’s motor. It’s not accessible, because it doesn’t need to be. There is no regular motor maintenance to be done by the owner. No changing the oil, no topping up the radiator. Tyres and windscreen wipers are the main things that need attention. Even brake pads and brake fluid last much longer than ICE cars because regenerative braking does 99% of the job when slowing down.

It doesn’t have full self-driving because (a) I wouldn’t trust that, and (b) it’s not legal in Australia.

Unfortunately, over the past four years Elon Musk has gone from “distasteful” to “serious candidate for worst person in the world”. My car now has a sticker that says “I bought this before we learned Elon was crazy”. The very first day the sticker was applied I got a yell of approval about it from another Tesla driver. Even though this car has been great for me I wouldn’t buy another Tesla now, because of the brand association and the general direction of the company. I also don’t want to sell it, because it’s working well for me, and I hate buying and selling cars, and it’s not obvious what non-Tesla EV is the best alternative. Hrmph.

Hot water

Two years ago I replaced my gas hot water tank with a Reclaim Energy one that uses an electric heat pump. It was pretty straightforward and the new tank has worked flawlessly.

I was always slightly terrified by just how intense the old gas tank’s flames were, that “whoosh” sound when it kicked in, and I’ve never liked the idea of a pilot light that was always burning. The new tank doesn’t feel like it could one day accidentally blow my house up. That’s a nice feeling.

Stove top

Shortly after I replaced the hot water tank I replaced my gas stove top with an Asko electric induction stove top. This required running a new electrical circuit to the kitchen. Fortunately the fusebox had enough capacity so it wasn’t a big deal.

Induction cooking takes a little getting used to and I had to replace some aluminium pots and pans with steel ones, but now I really like it. It can produce prodigious amounts of heat, even more than the old gas wok burner.

It is also an absolute dream to clean. I wipe it down in a few seconds every time after cooking. Compare that with the old gas stove top which I would clean half-heartedly about once a week and properly about once a quarter. I don’t miss those filthy metal rings and grates.

I also don’t miss the air pollutants from burning gas inside a house. Did you know that 12% of childhood asthma in Australia can be attributed to the use of gas stoves for cooking? The history of the study of air pollution on human health is basically a never-ending cycle of scientists concluding “it’s even worse than we thought”.

Heating

Last month I replaced the house’s heating and cooling system. I had a ducted system with a gas heater and an add-on air conditioner. It was fifteen years old and the air conditioner broke down irreparably. My house has some interesting space constraints and I received some opinions that I should switch to per-room split systems but I ended up choosing a ducted Daikin heat pump (a.k.a. reverse-cycle air conditioner) that heats and cools. Technology has come along nicely here: the new unit is more powerful but also quieter than the old system; it can run at multiple speeds instead of just being fully on or off; and it’s smaller, so I have a little more space along the side of the house.

Bits and pieces

I have made a request with the gas company to disconnect my house from the gas network and remove the gas meter. It should be done within a couple of weeks. My contribution to the gas death spiral.

I do still have one fossil fuel device: a barbecue powered by a gas bottle. But that barbecue gets used about twice a year and probably accounts for about 0.01% of the fossil fuels that were used by the old car, stove top, hot water tank, and heater, so I’m happy to treat it as a rounding error and declare victory.

You might be wondering about the usual question: how is the electricity used by these new machines generated? Before I answer that, note that these kinds of electric machines are generally less polluting even when run on electricity generated entirely from fossil fuels, because they are so much more energy-efficient. E.g. an EV typically converts more than 90% of energy in the battery into kinetic energy; the corresponding figure for an ICE car is more like 25-30%. Heat pumps and induction stove tops are also extremely efficient.

Fortunately, my situation is much better than that baseline. First, I have a small (2 KW) solar panel system that covers some of my electricy usage. Beyond that, most of my electricity does come from the grid, but more than 40% of Australia’s electricity supply is now renewable. That proportion has tripled in less than ten years, and the federal government has a target of 82% renewables by 2030 which appears to be more or less on target. So these new machines will become less polluting as time goes on.

Replacing any large machine is always a pain, but it’s worth noting that, even if you ignore the environmental side of things, the new electric machines are all better than the old fossil fuel machines they replace: quieter, safer, smoother, and cheaper to run. No hair shirts required.

Saul Griffith’s The Big Switch: Australia’s Electric Future is an excellent resource for anyone wanting to learn more about electrification.

Notable improvements

#124129: In this PR, Rémy Rakic made lld the default linker for the nightly compiler on x86-64/Linux. lld is much faster than the system linkers, and this change reduced the wall-time for several benchmark results by 30% or more. The idea of using lld first came up in 2017 and took a surprising amount of time and effort to get into a shippable state; many thanks to Rémy for getting it over the line. You can enable lld on other configurations by following these instructions. Manual enabling has been possible for a long time, but defaults matter and it’s good to get wider exposure for this feature. Read more in the announcement blog post. Work is underway to enable lld on stable releases.

#133807: In this PR, Kajetan Puchalski enabled PGO for ARM64/Linux, giving 10-20% speedups across pretty much all benchmarks on that platform. Great work!

#127513, #135763: In these PRs, Nikita Popov upgraded the LLVM version used by the compiler to LLVM 19 and then LLVM 20. These PRs gave a mean wall-time reduction across all benchmarks results of 1.33% and 0.78%. Every LLVM major update for several years has made the Rust compiler faster. This is not due to some law of nature. Rather, it reflects sustained, excellent work from the LLVM developers. Kudos to them.

#132566: In this PR, Ben Kimock made a hard-to-describe change to how monomorphization works. If we look just at incremental builds that involve code generation, it gave a mean wall-time reduction across all benchmark results of 5.00%, with a handful exceeding 20%. These results are somewhat inflated by an artifact of how the benchmarks are measured (see the PR description for details) and in practice the real improvements were probably between half and two-thirds of what was measured. Still a very impressive improvement for a single change.

#136771: In this PR, scottmcm simplified slice::Iter::next enough that it can be inlined. This resulted in a mean cycle reduction across all benchmark results of 0.34%. This change is likely to slightly speed up a lot of other Rust programs as well, because slice iteration is extremely common.

#133793: The Rust compiler has excellent error messages, but sometimes this comes at a performance cost. You may have seen syntax errors that look like this:

error: expected one of `:`, `@` or `|`, found `,`

To generate these, the parser maintained a vector of tokens called expected_token_types that was constantly updated. The compiler’s token type is more heavyweight than you might expect. It does not implement Copy and so the token pushing requires calls to clone and the clearing requires calls to drop. (I’m nearing the end of a long-term project to fix this.) In this PR I changed this vector to use a simpler type which made the pushing and clearing much cheaper. This gave icount wins across many benchmarks, the best being 2.5%.

#131481: I previously wrote about this PR of mine in a post about dataflow analysis. It was a small performance win, giving sub-1% instruction count reductions on a few benchmarks. But it was interesting because it involved removing a supposed optimization that was actually a pessimization in practice. Removing it made the code shorter (500+ lines of code removed). I don’t know if this “optimization” was always a pessimization. Perhaps it was once a speed win but that changed over time as other things around it changed. It’s a good reminder that writing high performance code isn’t easy, and it’s always good to keep measuring things.

Startup

There were also some improvements relating to startup.

#131634: In this PR David Lattimore used protected visibility for symbols when building rustc_driver. This is an arcane symbol/linker thing I won’t pretend to understand that somehow shaves about 10-12 million instructions off startup, on Linux at least. For a check build of “hello world” that was a 31% icount reduction!

#137586: This is a funny one. When profiling very short running compilations, e.g. a check build of “hello world”, the single hottest function was something in LLVM called SetImpliedBits. It accounted for almost 20% of the ~26 million instructions executed. This function is used when checking LLVM’s support for code generation features, such as SSE2, AVX, etc. On x86 and x86-64 CPUS there are 60+ such features that need to be checked. Each one requires the Rust compiler to call into LLVM, and the code on the LLVM side is very, uh, sub-optimal. Furthermore, I discovered that the Rust compiler was actually checking every feature twice, once when considering stable features and once when considering both stable and unstable features. In this PR I eliminated this second check for each feature, which gave almost 10% icount reductions in the best case. This benefit should be seen on x86 and x86-64 across all operating systems. On other architectures it will be smaller because they have fewer features to check.

LLVM #130936: Nikita Popov made a related change to fix the sub-optimal (“implemented in a really stupid fashion”) feature checking within LLVM. When the next LLVM major update happens we should see another ~10% icount win for “hello world”, and SetImpliedBits will no longer confuse people by clogging up Cachegrind profiles of these short-running compiler invocations.

The wall-time improvements of all these startup changes are likely in the order of a few milliseconds, which is too small to measure reliably. There are two ways to look at this. The pessimistic view is to observe that it’s well below what a human would notice. The optimistic view is to note that these milliseconds are shaved off every single invocation of the compiler, and this can only be a good thing. I choose the latter.

General Progress

For the period 2024-03-04 to 2025-03-17 we had some reasonably good overall performance results.

First, wall-time:

• There were 526 results measured across 43 benchmarks.
• 306 of these were improvements, and 220 were regressions. The mean change was a reduction of 6.37%. Plenty of the reductions were in the double digits, some exceeding 50%. Most of the regressions were in the single digits.

Next, peak memory usage:

• Again, there were 526 results measured across 43 benchmarks.
• 149 of these were improvements, and 377 were regressions. The mean change was a 2.87% increase, and most of the changes were in the single digits.

Finally, binary size:

• There were 324 results measured across 43 benchmarks.
• 178 of these were improvements, and 146 were regressions. The mean change was a 1.95% reduction, and most of the changes were in the single digits.
• If we restrict things to non-incremental release builds, which is the most interesting case for binary size, there were 17 improvements, 26 regressions, and the mean change was a reduction of 0.10%.

For all three metrics, all but a handful of results met the significance threshold. I haven’t bothered separating those results because they made little difference to the headline numbers. As always, these measurements are done on Linux.

In short, speed generally improved; memory usage regressed a small amount, probably not enough to be noticeable; and binary size didn’t change much.

Over the past year I have not spent that much time on compiler performance. For the rest of this year I hope to change that by working on both incremental compilation and parallelism in the front end. These are areas of the compiler that are complex, but have potential for significant speed improvements.

One final thing: we will be updating the rustc-perf benchmark suite soon, as per policy, because it has been three years since the last update. This will mostly consist of updating the real-world crate benchmarks (e.g. serde) to their latest versions. This is to ensure we are benchmarking representative code.