Rust compiler performance
kobzol.github.io
Rust compiler performance
1–10 of 264 posts
Re: Rust compiler performance
#2I'd vote for filesystem space utilization to be worked on before performance.
Re: Rust compiler performance
#3I'd vote for filesystem space utilization to be worked on before performance.
Is this not more a Cargo thing? Cargo is obsessed with correct builds and eventually the file system fills up with old artifacts.
(I know, I have to declare Cargo bankruptcy every few weeks and do a full clean & rebuild)
Re: Rust compiler performance
#4I'd vote for filesystem space utilization to be worked on before performance.
The problems are largely related. Cut down the amount of intermediate compilation artifacts by half and you'll have sped up the compiler substantially. Monomorphization and iterator expansion and such is a significant contributor to both issues.
Re: Rust compiler performance
#5I'd vote for filesystem space utilization to be worked on before performance.
Is this not more a Cargo thing? Cargo is obsessed with correct builds and eventually the file system fills up with old artifacts. (I know, I have to declare Cargo bankruptcy every few weeks and do a full clean & rebuild)
Correct builds != never running garbage cleanup. I would settle for it evicting older variants of a build (I also dislike the random hash that’s impossible to determine what specifically is different between two hashes / which one is newer).
Re: Rust compiler performance
#6I'd vote for filesystem space utilization to be worked on before performance.
One of the reasons I quit rust is literally because having 4-5 projects checked out that use serde would fill my laptop drive with junk in a few weeks.
Re: Rust compiler performance
#7Earlier quoted context omitted.
Is this not more a Cargo thing? Cargo is obsessed with correct builds and eventually the file system fills up with old artifacts. (I know, I have to declare Cargo bankruptcy every few weeks and do a full clean & rebuild)
Correct builds != never running garbage cleanup. I would settle for it evicting older variants of a build (I also dislike the random hash that’s impossible to determine what specifically is different between two hashes / which one is newer).
Automatic garbage collection of old build artifacts* is coming in Rust 1.88 (currently on the beta channel, will become the new stable release in two weeks):
https://github.com/rust-lang/cargo/issues/12633
*EDIT: For now this only deletes old cached downloads, not build artifacts. Thanks epage for the correction below.
Re: Rust compiler performance
#8I'd vote for filesystem space utilization to be worked on before performance.
This is one of the only reasons I disliked Haskell. GHC and lib files can easily take over 2GB of storage.
Re: Rust compiler performance
#9I wonder if how much value there is in skipping LLVM in favor of having a JIT optimized linked in instead. For release builds it would get you a reasonable proxy if it optimized decently while still retaining better debugability.
I wonder if the JVM as an initial target might be interesting given how mature and robust their JIT is.
Re: Rust compiler performance
#10Earlier quoted context omitted.
Correct builds != never running garbage cleanup. I would settle for it evicting older variants of a build (I also dislike the random hash that’s impossible to determine what specifically is different between two hashes / which one is newer).
Automatic garbage collection of old build artifacts* is coming in Rust 1.88 (currently on the beta channel, will become the new stable release in two weeks): https://github.com/rust-lang/cargo/issues/12633 *EDIT: For now this only deletes old cached downloads, not build artifacts. Thanks epage for the correction below.
That’s as an additional flag and not the default?