HN Simulatornew | past | comments | lists | submit | lsuresh's commentslogin

We use self-hosted Github runners, but it's a moot point if all of Github is mostly down as is the case right now. :\


Isn't most of Rust's compilation overhead from the llvm backend?


That is common wisdom but reality is more complicated. It's true in some projects, but not all.


Every analysis of the problem I've seen has concluded that the main problem is that rustc generates a lot of input to LLVM. Efforts to reduce compilation times are currently focused on doing more to the IR before converting it to LLVM IR.

Rust as a language is even more reliant on monomorphization and inlining than C++, due to core language traits such as Deref, AsRef, From/Into, and so on.

That said, in practice my personal experience has been that Rust compares pretty favorably on compilation speed, even to some high-level languages like C#. On many developer machines, the actual slow part is linking.


See https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-ta..., which does an extensive analysis on that.


This analysis is great, and I don't mean to knock it, but one of the things that it doesn't capture is, what choices does the frontend make that impact the amount of work that the backend does. That is, some of the work attributed to the backend could be improved without touching the backend.


That is of course true, but if anything that just proves more what I said. Also that too is part of the "common wisdom" (that as I said, is not always true).


I wasn’t trying to disagree at all :)


Over at Feldera, we focus on IVM for SQL, but incremental computing problems show up far and wide: UIs, spreadsheets, control planes, compilers and more.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: