Hacker News Reader

Comment by andrewchambers | Hacker News Reader

What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else.

LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.

View on HN

On debug builds, it's about evenly split between typeck/borrowck and codegen (including LLVM IR construction and LLVM passes). On release builds, LLVM optimization time tends to dominate everything.

Niko Matsakis is actively working on improving typechecking time--there should be plenty of tricks we can try once we have enough data as to the lowest-hanging fruit. Felix Klock and others are working on reducing the amount of LLVM IR we generate to speed up codegen. There have also been designs for incremental and parallel compilation that will be long-term but have potential for big improvements down the road.

I think with careful work we can get down to a good edit/compile/run experience. Compilation speed probably won't ever be as good as a direct-to-assembly compiler for language with an extremely simple type system with no real IR for optimization would be, but I don't believe there's a magic bullet that will beat LLVM's compiler performance while providing excellent optimization, and for Rust's goals we need the runtime performance.

Is rustc able to run typechecking without doing codegen?

`rustc .... -Z no-trans`. kibwen is working on a mode where rustc can generate crates with just metadata, and use it for a `cargo check` mode.

I think a big issue is that even if it takes a few more seconds, it is still a big win compared with C and C++ builds, usually measured in hours.

But I guess it is a block for those used to programming languages with traditional interpreter implementations.

My biggest complain when trying out Rust was the C++ build times of the bootstrapping process. As for using pre-compiled Rust, I think the compile times are pretty acceptable for 1.0.

> C and C++ builds, usually measured in hours. Do you have a source or a story about this? I hadn't heard numbers like that before.

The slowest part is LLVM. (You can pass "-Z time-passes" to rustc to get detailed timing info.)

This isn't just an "LLVM is slow" problem, though. It's also a "rustc generates extremely verbose LLVM IR" problem. Optimizing the IR before it gets to LLVM is part of the plan for solving it.

It's also a "let's rebuild everything every time" problem. Hopefully, that will be fixed with support for building incrementally.

(Also note that compiling a C++ file with 2000 lines can take a very long time too)

You must not forget that thanks to the preprocessor, what looks like 2000 lines may in fact be around 200k lines

E.g. I have a very innocent 2000-line MainWindow.cpp that weighs 244419 lines when measured with gcc -E -o - | wc -l

Good point, it really is quite staggering what a C++ compiler has to digest to compile a standard "Hello, World!". Hopefully the much-anticipated module system will help here. Generally I find that avoiding Boost libraries (including std::regex) helps enormously ;)

> What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else.

I feel like there are some projects out there that trigger things with bad runtime complexities in Rust. I had to stop using the piston image library because compiling it takes 15 seconds every time, which I'm not in for.

Compiling racer currently needs 2GB of RAM for no good reason.

So I'm pretty sure there is ample room for optimizations.

Reply on news.ycombinator.com