|
|
@pcwalton | |||||
|
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.
|
||||||
|
||||||
|
|
Patrick Walton
@pcwalton
|
2. velj |
|
(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.
|
||
|
|
||
|
Tony “Abolish ICE” Arcieri 🦀
@bascule
|
3. velj |
|
How about a secure distribured compiler cache?
|
||
|
|
||
|
CuddleViper
@CuddleViper
|
21 h |
|
Could define secure? What are the requirements here?
|
||
|
|
||
|
Lefteris Stamatogiannakis
@estama2
|
2. velj |
|
What % of the total compilation time is due to the checks? Maybe a quick no-check compilation mode would be beneficial for quick edits? Programming has a rhythm where big changes are followed by many smaller ones. A no-check compilation may be useful for the small changes.
|
||
|
|
||
|
Rich Felker
@RichFelker
|
3. velj |
|
Seems you'd always want no-check when building as a user rather than a developer unless you distrust upstream...
|
||
|
|
||
|
AVX-512
@512Avx
|
3. velj |
|
trait bounds resolution has something extremely non linear in it, i can point to that
|
||
|
|
||
|
AVX-512
@512Avx
|
3. velj |
|
i guess i should do the work if creating a minimal example and submit a pr
|
||
|
|
||
|
glandium
@MikeHommey
|
3. velj |
|
@nnethercote's work would tend to contradict this.
|
||
|
|
||
|
Nicholas Nethercote
@nnethercote
|
3. velj |
|
I would say that 3 years ago it wasn't well optimized, and finding improvements was really easy. Today it's much harder. So I think "pretty well optimized" is a reasonable description.
|
||
|
|
||
|
Dmitry Popov
@thedeemon_lj
|
15 h |
|
LLVM? Has anyone seen an LLVM-based compiler these days that wasn't slow?
|
||
|
|
||