←back to thread

Why is the Rust compiler so slow?

(sharnoff.io)
302 points Bogdanp | 5 comments | 26 Jun 25 19:29 UTC | HN request time: 0.001s | source
Show context
taylorallred ◴[26 Jun 25 20:29 UTC] No.44390996[source]▶
So there's this guy you may have heard of called Ryan Fleury who makes the RAD debugger for Epic. The whole thing is made with 278k lines of C and is built as a unity build (all the code is included into one file that is compiled as a single translation unit). On a decent windows machine it takes 1.5 seconds to do a clean compile. This seems like a clear case-study that compilation can be incredibly fast and makes me wonder why other languages like Rust and Swift can't just do something similar to achieve similar speeds.
replies(18): >>44391046 #>>44391066 #>>44391100 #>>44391170 #>>44391214 #>>44391359 #>>44391671 #>>44391740 #>>44393057 #>>44393294 #>>44393629 #>>44394710 #>>44395044 #>>44395135 #>>44395226 #>>44395485 #>>44396044 #>>44401496 #
vbezhenar ◴[26 Jun 25 21:40 UTC] No.44391740[source]▶
I encountered one project in 2000-th with few dozens of KLoC in C++. It compiled in a fraction of a second on old computer. My hello world code with Boost took few seconds to compile. So it's not just about language, it's about structuring your code and using features with heavy compilation cost. I'm pretty sure that you can write Doom with C macros and it won't be fast. I'm also pretty sure, that you can write Rust code in a way to compile very fast.
replies(2): >>44391871 #>>44394831 #
taylorallred ◴[26 Jun 25 21:54 UTC] No.44391871[source]▶
I'd be very interested to see a list of features/patterns and the cost that they incur on the compiler. Ideally, people should be able to use the whole language without having to wait so long for the result.
replies(3): >>44391972 #>>44392259 #>>44394858 #
1. vbezhenar ◴[26 Jun 25 22:56 UTC] No.44392259{3}[source]▶
So there are few distinctive patterns I observed in that project. Please note that many of those patterns are considered anti-patterns by many people, so I don't necessarily suggest to use them.

1. Use pointers and do not include header file for class, if you need pointer to that class. I think that's a pretty established pattern in C++. So if you want to declare pointer to a class in your header, you just write `class SomeClass;` instead of `#include "SomeClass.hpp"`.

2. Do not use STL or IOstreams. That project used only libc and POSIX API. I know that author really hated STL and considered it a huge mistake to be included to the standard language.

3. Avoid generic templates unless absolutely necessary. Templates force you to write your code in header file, so it'll be parsed multiple times for every include, compiled to multiple copies, etc. And even when you use templates, try to split the class to generic and non-generic part, so some code could be moved from header to source. Generally prefer run-time polymorphism to generic compile-time polymorphism.

replies(2): >>44392908 #>>44402983 #
2. dieortin ◴[27 Jun 25 00:52 UTC] No.44392908[source]▶
Why use C++ at that point? Also, pre declaring classes instead of including the corresponding headers has quite a few drawbacks.
replies(2): >>44393023 #>>44394674 #
3. kortilla ◴[27 Jun 25 01:23 UTC] No.44393023[source]▶
RAII? shared pointers?
4. maccard ◴[27 Jun 25 07:49 UTC] No.44394674[source]▶
References, for one. Also there’s a huge difference between “avoid templates unless necessary” and “don’t use templates”.
5. pjmlp ◴[28 Jun 25 07:57 UTC] No.44402983[source]▶
C++23 modules make 2. a moot point.

Same applies to point 3, when used alongside external templates.