How to speed up the Rust compiler in September 2026
31 points by patchunwrap
31 points by patchunwrap
i can't seem to find a specific name for the next-gen trait solver, so "Penelope Hammertime" it is!
#160506: The project uses a lot of “rollup” PRs, where multiple PRs are merged together. This is because we don’t have sufficient CI capacity to merge every PR individually. Normally PRs that affect performance are merged by themselves so we can measure their effects clearly. For the first time ever, at one point we had so many performance improvement PRs waiting in the merge queue that Jonathan Brouwer created a rollup containing 10 performance-improving PRs to keep things moving!
I feel like I got bit by this because in my mind the Github merge queue was supposed to be optimistic: just optimistically try to build "everything" and then (for example) bisect on a failed merge. Instead I've ended up having to still build everything in the queue.
I guess I was expecting a merge queue to be more like a ... I dunno, merge stack? And it sounds like Rust could benefit from a similar thing. Maybe.
Very impressive work!!
#159642: In this PR Jakub Beránek enabled PGO for Clippy
What is PGO? I looked in the linked issue but it doesn’t say anything about it either.
It stands for Profile-guided optimisation. The idea is that you compile the program once normally, then run it for a while under typical usage and measure (profile) the code to see (for example) which parts are "hot" and execute most often. You can then compile the program a second time using this data to prioritise optimising for those hot functions (amongst other things).