Rust compiler performance • Hacker News Board

Re: Rust compiler performance

#11

Post by epage » Thu, Jun 12, 2025, 4:29 PM UTC

stevedonovan wrote: post #3

dboreham wrote: post #2

I'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)

A little of both. Incremental compilation cache is likely the single largest item in the target directory but it gets cleaned up on each invocation so it doesn't scale in size with time.

I believe the next release will have a cache GC but only for global caches (e.g. `.crate` files). I'd like us to at least cleanup the layout of the target directory so its easier to track stuff before GCing it. Work is underway for this. A cheap GC we could add earlier is for artifacts specific to older cargo versions.

Re: Rust compiler performance

#12

Post by epage » Thu, Jun 12, 2025, 4:30 PM UTC

mbrubeck wrote: post #7

vlovich123 wrote: post #5

Earlier 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 is not for build artifacts but global caches like for `.crate` files but its a stepping stone.

Re: Rust compiler performance

#13

Post by MeetingsBrowser » Thu, Jun 12, 2025, 4:31 PM UTC

dboreham wrote: post #2

I'd vote for filesystem space utilization to be worked on before performance.

Why not both?

If I had to choose though, I would choose compilation speed. Buying an SSD to double my storage is much more cost effective than buying a bulkier processor to halve my compilation times.

Re: Rust compiler performance

#14

Post by mbrubeck » Thu, Jun 12, 2025, 4:31 PM UTC

vlovich123 wrote: post #10

mbrubeck wrote: post #7

Earlier quoted context omitted.

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?

In versions earlier than 1.88, garbage collection required the unstable -Zgc flag (and a nightly toolchain). But in 1.88 and later, automatic garbage collection is enabled by default.

Re: Rust compiler performance

#15

Post by mbrubeck » Thu, Jun 12, 2025, 4:34 PM UTC

epage wrote: post #12

mbrubeck wrote: post #7

Earlier quoted context omitted.

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 is not for build artifacts but global caches like for `.crate` files but its a stepping stone.

Oops, thanks for the correction.

Re: Rust compiler performance

#16

Post by kzrdude » Thu, Jun 12, 2025, 4:37 PM UTC

dboreham wrote: post #2

I'd vote for filesystem space utilization to be worked on before performance.

Performance has been worked on since Rust 1.0 or so, for all this time, there has been lots of work on compiler performance. There's no "before performance" :)

Re: Rust compiler performance

#17

Post by jplusequalt » Thu, Jun 12, 2025, 4:53 PM UTC

Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.

Re: Rust compiler performance

#18

Post by preciousoo » Thu, Jun 12, 2025, 4:55 PM UTC

dboreham wrote: post #2

I'd vote for filesystem space utilization to be worked on before performance.

What’s stopping cargo from storing libraries in one global directory(via hash or whatever), to be re-used whenever needed?

Re: Rust compiler performance

#19

Post by jakkos » Thu, Jun 12, 2025, 4:58 PM UTC

dboreham wrote: post #2

I'd vote for filesystem space utilization to be worked on before performance.

Not that this isn't a problem, it is, target folders currently take up ~100gb on my machine but...

I'd still, by far, prefer a tiny incremental compile speed increase over a substantial storage reduction. I can get a bigger SSD, I can't get my time back :'(

Re: Rust compiler performance

#20

Post by estebank » Thu, Jun 12, 2025, 4:58 PM UTC

MeetingsBrowser wrote: post #13

dboreham wrote: post #2

I'd vote for filesystem space utilization to be worked on before performance.

Why not both? If I had to choose though, I would choose compilation speed. Buying an SSD to double my storage is much more cost effective than buying a bulkier processor to halve my compilation times.

> Why not both?

For better and worse, the Rust project is a "show-up-ocracy": the work that gets done is the one that volunteers (or paid employees from a company donating their time to the project) spend time doing. It's hard in open source projects to tell people "this is important and you must work on it", but rather you have to convince people that it is important and have to hope they will have the time, inclination and skill to work on it.

FWIW, people were working on the cargo cache GC feature years ago[1], but I am not aware of what the current state of that is. I wouldn't be surprised if it wasn't turned on because there are unresolved questions.

1: https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning/