Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Compile Times and Code Graphs

blog.danhhz.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Rust Compile Times and Code Graphs

#11

Post by Nullabillity »

mxz3000 wrote: post #3
wredue wrote: post #2

2 minutes isn’t even really bad build times. I think that part of “compile times suck” is that, when we are learning, we are building extremely small programs. Hundreds of lines at the very top end. During this phase of our personal development, we build a habit of writing a line of code, then compiling. Then changing an index, then compiling. Then realize we use a wrong variable, then compile. Then then compile. Som…

if you have a reasonably good IDE you don't really need to explicitly compile the whole program outside of when you want to run it.

Because that IDE is compiling the code behind the scenes... (Usually somewhere on a spectrum between literally just using the real compiler, or failing spectacularly to match it.)

Re: Rust Compile Times and Code Graphs

#12

Post by pjmlp »

bbatha wrote: post #8
pjmlp wrote: post #7

Earlier quoted context omitted.

Which is exactly what we need when doing GUI and games in Rust. If it can't compete with the compile times from. NET, Java, Dart, Typescript then it won't be used by most folks. C++ already lost the GUI wars for a reason, now stuck being the low level implementation language for GUI frameworks, driven by other languages.

IME Typescript generally has far worse compile times than rust especially if you need to start splitting into packages or do anything more complex than stripping type annotations.

It never took me 15 minutes, like on a Gtk+rs project I have.

Re: Rust Compile Times and Code Graphs

#13

Post by vlovich123 »

estebank wrote: post #10
vlovich123 wrote: post #5

I really dislike the need to artificial decompose crates in this way. If Rust could accurately track dependencies at a more fine-grained level, then no one would do this because it adds complexity. It’s like optimizing assembly but for build systems. What I mean by this is that if Rust tracked dependency information at the level of “my function too dependent on type declarations XYZ from crate A” vs “my function depe…

That could indeed be done (and I want to make that happen at some point), but you must be aware that this is an optimization, and as such trivial unrelated code changes can make the compile times balloon because all of a sudden you added a field to a struct with a type that used to fall on the division boundary, and you went from multiple pseudo-crates to a single one. This kind of behavior is hell to debug and figur…

I'm not sure I'm following the scenario described, but I don't see how the debugging complexity is more difficult than at the crate level. Can you help me understand why this might be the case? I'm not sure what you're calling as division boundaries / pseudo-crates here (are you suggesting that the dependency tracking won't be fine-grained & trivial changes can cause false sharing or something else?).

Doing all this tracking correctly though across layers of compilers is tricky if you want to shoot for absolute optimal performance. At the limit for truly optimal behavior, you'd track all the input information the compiler used when generating code and map it back to the source level (i.e. did I inline function A into function B - then I need to regenerate function A if B changes, but if no inline then don't regenerate A), which can be hard as most compiler optimization passes are information destroying. So yeah, I don't doubt that whatever "practical" middle ground is found as a realistic implementation can be tricky to reason about, but I suspect it almost doesn't matter if done well because it'll always outperform what you would have done by hand as outlined in this post / do it for you for free in 90% of cases.

Re: Rust Compile Times and Code Graphs

#14

Post by trealira »

TinkersW wrote: post #9
wredue wrote: post #2

2 minutes isn’t even really bad build times. I think that part of “compile times suck” is that, when we are learning, we are building extremely small programs. Hundreds of lines at the very top end. During this phase of our personal development, we build a habit of writing a line of code, then compiling. Then changing an index, then compiling. Then realize we use a wrong variable, then compile. Then then compile. Som…

Depends if that 2 minutes is full build or incremental..if incremental that is unacceptable, should be more like 2 seconds. Compiling to see if you have syntax errors? What do you not have an editor?

Yeah, and cargo check exists for that very reason. It does type checking without actually compiling the code. Rust-analyzer, the LSP server for Rust, runs `cargo check` whenever the file is saved, IIRC, and then shows you what the compiler said.

Re: Rust Compile Times and Code Graphs

#15

Post by IshKebab »

vlovich123 wrote: post #13
estebank wrote: post #10

Earlier quoted context omitted.

That could indeed be done (and I want to make that happen at some point), but you must be aware that this is an optimization, and as such trivial unrelated code changes can make the compile times balloon because all of a sudden you added a field to a struct with a type that used to fall on the division boundary, and you went from multiple pseudo-crates to a single one. This kind of behavior is hell to debug and figur…

I'm not sure I'm following the scenario described, but I don't see how the debugging complexity is more difficult than at the crate level. Can you help me understand why this might be the case? I'm not sure what you're calling as division boundaries / pseudo-crates here (are you suggesting that the dependency tracking won't be fine-grained & trivial changes can cause false sharing or something else?). Doing all this…

He's saying that if you explicitly separate your crates out, and then you accidentally introduce a circular dependency you will get a compile time error. But if you have one big crate and rely on the compiler to detect internal dependencies for performance, then when you accidentally introduce a dependency that you didn't mean to it will happily compile but it will be slower so you probably won't notice and it will be really hard to debug.

Re: Rust Compile Times and Code Graphs

#16

Post by kamikaz1k »

bbatha wrote: post #8
pjmlp wrote: post #7

Earlier quoted context omitted.

Which is exactly what we need when doing GUI and games in Rust. If it can't compete with the compile times from. NET, Java, Dart, Typescript then it won't be used by most folks. C++ already lost the GUI wars for a reason, now stuck being the low level implementation language for GUI frameworks, driven by other languages.

IME Typescript generally has far worse compile times than rust especially if you need to start splitting into packages or do anything more complex than stripping type annotations.

Depends on what you're doing. If you're type checking, it's usually happening in the background via LSP. If you're "compiling" to JS, use esbuild and its instant.

Re: Rust Compile Times and Code Graphs

#17

Post by dist1ll »

trealira wrote: post #14
TinkersW wrote: post #9

Earlier quoted context omitted.

Depends if that 2 minutes is full build or incremental..if incremental that is unacceptable, should be more like 2 seconds. Compiling to see if you have syntax errors? What do you not have an editor?

Yeah, and cargo check exists for that very reason. It does type checking without actually compiling the code. Rust-analyzer, the LSP server for Rust, runs `cargo check` whenever the file is saved, IIRC, and then shows you what the compiler said.

Incremental type checking is still painfully slow on a large codebase.
Post reply on HN