|
|
@pcwalton | |||||
|
(2) There’s no high-profile language design decision you can point to and say “aha, that was a mistake!” No header files, for example. The slowness comes from a lot of smaller things that have real benefits, such as the borrow check.
|
||||||
|
||||||
|
|
Patrick Walton
@pcwalton
|
2. velj |
|
Rust compiler performance is hard to have meaningful discussions about because:
(1) There’s no single part of the compiler which is slow. In fact the compiler is pretty well optimized.
|
||
|
|
||
|
Zorro Notorious M. E. B he / him
@znmeb
|
3. velj |
|
I don't know about whether this is meaningful to a language like Rust, but back in the 1960s / 70s when there was massive investment in Fortran compiler technology, there were two types of compilers:
|
||
|
|
||
|
Zorro Notorious M. E. B he / him
@znmeb
|
3. velj |
|
1. Highly optimizing compilers - they spent a lot of compile time grinding out the best code they could. All the tricks in the book were fair game.
2. "Student" compilers, like WATFOR - they were optimized for compile speed. They were glorified macro assemblers.
|
||
|
|
||
|
Rik Arends
@rikarends
|
2. velj |
|
Seems like there may be only one path then: be more incremental. First time compile is alright since you can sortof manage that yourself by not snowballing deps. But i'd love the ability to change small bits of code and hotload them rapidly. Doing that now for shaders but yea.
|
||
|
|
||
|
Darius Jahandarie
@djahandarie
|
2. velj |
|
I think the basic architectural decision to make the compiler offline (instead of an online differential/incremental dataflow) is one thing that makes it “slow” (where “slow” is to be understood as something which lengthens the development feedback cycle).
|
||
|
|
||
|
Paolo G. Giarrusso
@Blaisorblade
|
2. velj |
|
Honest question: is there any evidence that *fine-grained* incrementalization would help *in a compiler for such a complex language*? Embarrassingly parallel tasks parallelize well, but compilation ain't it, even if you ignore monomorphization.
|
||
|
|
||
|
Saoirse Shipwreckt
@withoutboats
|
2. velj |
|
I think there are some clear unforced errors like name resolution (though these matter more for IDE responsiveness than batch throughput)
|
||
|
|
||
|
Connie Hilarides
@Connicpu
|
3. velj |
|
Is the borrow checker even what's slow? I always thought llvm was the big bottle neck even in debug builds
|
||
|
|
||
|
infinitesimal
@infinitesimal_p
|
2. velj |
|
Does the borrow checker *need* to be slow, though?
|
||
|
|
||
|
soc
@oxnrtr
|
2. velj |
|
Tests in main sources?
|
||
|
|
||
|
lambic pentameter
@jcdyer
|
3. velj |
|
#[cfg(test)]
|
||
|
|
||