GoKawiilYou might find this post especially useful if you have a project with many #[sqlx::test] tests.
One of the upstream Rust projects that I worked on during the past few years was the rewrite of bors , the merge queue bot we use to merge all rust-lang/rust PRs. If you are interested in learning more about this bot, check out my talk from RustWeek 2026.
I’m quite proud of the integration test suite of bors , which I spent a lot of effort on, and thanks to which the bot has been working pretty much flawlessly since we deployed it to production in January 2026 (despite GitHub lately often having… troubles).
One thing that I’m not very happy about though is the incremental rebuild time of bors , and in particular its test suite. It takes a long time (~8-10s) to rebuild the tests after each change on my laptop, which is quite bad for productivity.
Recently I finally found some time to profile its build time, and learned that it is caused by a combination of several factors:
Generation of debug information takes a long time. This is a known issue, but in this case I didn’t want to give up debug info, because I actually debug and step through bors tests quite often.
tests quite often. rustc takes a long time to load and persist the incremental session. I plan to take a look into this.
takes a long time to load and persist the incremental session. I plan to take a look into this. Probably because of all the debuginfo (the final binary has like 220 MiB), it takes lld a whole second (!) to link the tests. With wild , it’s just ~200ms.
a whole second (!) to link the tests. With , it’s just ~200ms. The sqlx::test s that I am using heavily in bors take a long time to compile. This is what I will focus on in this post.
Slow compilation of sqlx tests
... continue reading