Why Cargo Check Is So Slow
23 comments
·August 9, 2025ben_w
eveeifyeve
Also you have the ability to mute it by hovering over music by ... from ... and then a mute button will show.
eveeifyeve
Well I will soon have a mute pause and play at the music provided by ... And also I don't see this being linked to: https://eveeifyeve.pages.dev/http://localhost:4321/blogs/car...
ben_w
When I clicked on it here in HN, that URL (with localhost:4321) was where I went.
Either someone's edited that since then, or a weird auto-redirect on your server happened.
eveeifyeve
Weird idk blame cloudflare.
echelon
I love the auto-playing music. It reminds me of the Geocities-era web.
andrewflnr
Did you actually like it back then?
ameliaquining
I'm confused about a couple things:
* What is metadata_decode_entry_impl_trait_header and what does it have to do with proc macros? I suppose if a proc macro emitted code that used impl Trait a bunch then it might need to use this code, but I don't see why that would disproportionately affect compile times.
* What's the proposal for how to fix this?
eveeifyeve
It's used to compile proc macros. in order to fix this typeck needs to not use them which is a huge rewrite alone.
burnt-resistor
Neat.
I use bacon with cargo-make to toggle between check, nextest+doctest, and a full series of pre-commit checks.
piinbinary
I wonder why procmacros are slow. Can the compiler interpret them or does it have to go to all the work of compiling them before they can run?
Philpax
It has to compile them; you can see the compiled binaries in your `target` directory. Rust doesn't have an interpreter for the full language, only for the `const` subset, so it can't interpret them.
There have been some proposals to compile the proc-macros to WASM and share those alongside the code in crates.io, but nothing substantial has come of it.
LegionMammal978
It does have an interpreter for the full language, that's what Miri uses [0]. In fact, Miri doesn't even have its own evaluator, it just adds additional features to the rustc const-evaluation. The big limitations are that it doesn't have much support for syscalls or other calls into non-Rust code, and it emulates all multithreaded code on a single thread.
pjmlp
That is an implementation detail, but yeah so far other areas have been given more priority.
LoganDark
> Rust doesn't have an interpreter for the full language
Ever since a while ago, rustc uses Miri for const evaluation. So there are a lot of things it can do that it used to not be able to do. But, yes, const evaluation is limited to things that are part of the `const` subset.
LegionMammal978
As far as I'm aware, it's always been the other way around: Miri adds some features on top of rustc's const-evaluation code. The limitations of the latter are mainly self-imposed, due to the issues of exposing the different runtime models to programs. (E.g., you don't want to create allocations in const code that get deallocated at runtime.) Indeed, since 2019, the full functionality can be exposed with the unstable -Zunleash-the-miri-inside-of-you flag [0].
CodesInChaos
Is this complaint only about initial checks? Or also checks after a small change?
klas_segeljakt
#![forbid(proc_macros)]
null
echelon
Feature request: Rust proc macros and compile time statistics need to be called out on crates.io
We're starting to ban them from our Rust monorepo.
tayo42
Doesn't that prevent you from using some of the most useful crates?
eveeifyeve
Kinda but there is good usage of proc macros and bad usage.
What you linked to is a 404.
You're linking to https://eveeifyeve.pages.dev/http://localhost:4321/blogs/car...
You meant to link to https://eveeifyeve.pages.dev/blogs/cargo-check-slow.mdx/
Also, ew, auto-playing music.