←back to thread

302 points Bogdanp | 3 comments | | HN request time: 0.636s | source
Show context
taylorallred ◴[] 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 #
lordofgibbons ◴[] No.44391100[source]
The more your compiler does for you at build time, the longer it will take to build, it's that simple.

Go has sub-second build times even on massive code-bases. Why? because it doesn't do a lot at build time. It has a simple module system, (relatively) simple type system, and leaves a whole bunch of stuff be handled by the GC at runtime. It's great for its intended use case.

When you have things like macros, advanced type systems, and want robustness guarantees at build time.. then you have to pay for that.

replies(9): >>44391549 #>>44391582 #>>44391630 #>>44391910 #>>44394240 #>>44395833 #>>44397304 #>>44401934 #>>44402705 #
ChadNauseam ◴[] No.44391549[source]
That the type system is responsible for rust's slow builds is a common and enduring myth. `cargo check` (which just does typechecking) is actually usually pretty fast. Most of the build time is spent in the code generation phase. Some macros do cause problems as you mention, since the code that contains the macro must be compiled before the code that uses it, so they reduce parallelism.
replies(3): >>44391716 #>>44392132 #>>44397412 #
tedunangst ◴[] No.44392132[source]
I just ran cargo check on nushell, and it took a minute and a half. I didn't time how long it took to compile, maybe five minutes earlier today? So I would call it faster, but still not fast.

I was all excited to conduct the "cargo check; mrustc; cc" is 100x faster experiment, but I think at best, the multiple is going to be pretty small.

replies(2): >>44392588 #>>44395154 #
ChadNauseam ◴[] No.44392588[source]
Did you do it from a clean build? In that case, it's actually a slightly misleading metric, since rust needs to actually compile macros in order to typecheck code that uses them. (And therefore must also compile all the code that the macro depends on.) My bad for suggesting it, haha. Incremental cargo check is often a better way of seeing how long typechecking takes, since usually you haven't modified any macros that will need to be recompiled. On my project at work, incremental cargo check takes `1.71s`.
replies(2): >>44397210 #>>44402957 #
1. pjmlp ◴[] No.44402957[source]
That is something I never have to care on my C++ projects, because I always make use of binary libraries, unless I am forced to compile from source.

Unfortunately that doesn't seem to ever be a scenario cargo will support out of the box.

replies(1): >>44409017 #
2. ChadNauseam ◴[] No.44409017[source]
The actual reason that you don't have to care about this on your C++ project is because C++ doesn't let you define macros in C++, you can only define them in the preprocessor language. Therefore no compilation is needed to execute them.
replies(1): >>44410977 #
3. pjmlp ◴[] No.44410977[source]
I never write macros in C++, other than header guards, for years now.

I belong to the school of thought that C style macros in C++ should be nuked.

Exception being source code I don't own.