> When does the Rust compiler spend most of it's time? Is it at the checking stage?

rustc has a self-profiler that can be used to answer this question [0], as well as a mode that times compiler passes [1].

There's no single reason the Rust compiler is slow, as it depends quite heavily on the code being compiled. For some codebases, LLVM code takes up most of the time; in other codebases (e.g., extremely generic-heavy codebases), it'll be checking-related passes.

[0]: https://github.com/rust-lang/measureme/blob/master/summarize...

[1]: https://wiki.alopex.li/WhereRustcSpendsItsTime

Oh come on now, do you and the parent really have to be those guys who go "well technically they're not zero cost because the programmer has to wait"?

Yes, you're technically correct, but also being unreasonable.

It was pretty clear that "zero cost abstractions" refers to the runtime aspect. That is the default meaning, there's nothing to "get back to".

Huh? That was exactly my point.

there are some rust programs where the most time is spent in llvm, others hit slow paths in trait bounds analysis, others hit other spots. there is no single hotpath

It isn’t even zero runtime cost abstraction though. Monomorphizing all generic functions increases code size. Increased code size causes more instruction cache pressure which may actually slow things down, depending on the application. I could imagine if you’ve got some very large functions that are called on a wide variety of objects then every call could blow out the Icache and kill the hit rate.

It's an abstraction over writing out the monomorphized version by hand. Zero-cost doesn't mean using the abstraction gets you the fastest possible implementation of whatever you're doing.