←back to thread

Why is the Rust compiler so slow?

(sharnoff.io)
302 points Bogdanp | 2 comments | 26 Jun 25 19:29 UTC | HN request time: 0.001s | source
Show context
AndyKelley ◴[26 Jun 25 20:16 UTC] No.44390865[source]▶
My homepage takes 73ms to rebuild: 17ms to recompile the static site generator, then 56ms to run it.

    andy@bark ~/d/andrewkelley.me (master)> zig build --watch -fincremental
    Build Summary: 3/3 steps succeeded
    install success
    └─ run exe compile success 57ms MaxRSS:3M
       └─ compile exe compile Debug native success 331ms
    Build Summary: 3/3 steps succeeded
    install success
    └─ run exe compile success 56ms MaxRSS:3M
       └─ compile exe compile Debug native success 17ms
    watching 75 directories, 1 processes
replies(8): >>44390894 #>>44390942 #>>44390948 #>>44391020 #>>44391060 #>>44391265 #>>44391881 #>>44393741 #
vlovich123 ◴[26 Jun 25 20:25 UTC] No.44390948[source]▶
Zig isn’t memory safe though right?
replies(3): >>44391142 #>>44391516 #>>44391617 #
pixelpoet ◴[26 Jun 25 20:43 UTC] No.44391142[source]▶
It isn't a lot of things, but I would argue that its exceptionally (heh) good exception handling model / philosophy (making it good, required, and performant) is more important than memory safety, especially when a lot of performance-oriented / bit-banging Rust code just gets shoved into Unsafe blocks anyway. Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge

What I'm more interested to know is what the runtime performance tradeoff is like now; one really has to assume that it's slower than LLVM-generated code, otherwise that monumental achievement seems to have somehow been eclipsed in very short time, with much shorter compile times to boot.

replies(2): >>44391457 #>>44393291 #
1. vlovich123 ◴[26 Jun 25 21:14 UTC] No.44391457[source]▶
> Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge

> Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space)

With significant performance and memory overhead. That just isn't the same ballpark that Rust is playing in although hugely important if you want to bring forward performance insensitive C code into a more secure execution environment.

replies(1): >>44394864 #
2. mike_hearn ◴[27 Jun 25 08:19 UTC] No.44394864[source]▶
Fil-C has advanced a lot since I last looked at it:

> Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases.

with room for optimization still. Compatibility has improved massively too, due to big changes to how it works. The early versions were kind of toys, but if Filip's claims about the current version hold up then this is starting to look like a very useful bit of kit. And he has the kind of background that means we should take this seriously. There's a LOT of use cases for taking stuff written in C and eliminating memory safety issues for only a 50% slowdown.