What part of Rust compilation is the bottleneck?
kobzol.github.io
What part of Rust compilation is the bottleneck?
1–10 of 62 posts
Re: What part of Rust compilation is the bottleneck?
#2Good article, just throwing out there that flamegraphs would be exactly what you need for visualizing this stuff.
Re: What part of Rust compilation is the bottleneck?
#3FWIW Jakub has more blog posts on his website which are also really interesting https://kobzol.github.io/
Re: What part of Rust compilation is the bottleneck?
#4Good article, just throwing out there that flamegraphs would be exactly what you need for visualizing this stuff.
It looks like the profile they're build on already supports those, I think the intention here is to present a sort of at a glance view that could be quickly analyzed.
Re: What part of Rust compilation is the bottleneck?
#5Could LLVM be speeded up by passing it the data in a more efficient structure? Or by slimming down the data it's passed in some way?
Re: What part of Rust compilation is the bottleneck?
#6If you make a small change to your application, the Rust compiler does a significant amount of rework. That is, it recompiles a lot of code that it has already compiled before. There are valid technical reasons for this because of how LLVM works or that the linker needs to rewrite all addresses. Yes, incremental compilation is a thing but it’s too coarse IMO. To me it seems that taking an extremely fine grained approach to compilation would improve the ergonomics of the iterative hack-and-run method of writing software. Some sort of local database of diffs or some such.
Re: What part of Rust compilation is the bottleneck?
#7One reason for me moving from Rust to Go was compilation speed. Go is a simpler language, so apples to oranges, but Go compiles so fast, which to me makes development very different.
Re: What part of Rust compilation is the bottleneck?
#8Could LLVM be speeded up by passing it the data in a more efficient structure? Or by slimming down the data it's passed in some way?
It’s well known that the LLVM IR bytecode generated by rustc is terribly verbose – Rust constructs mostly get lowered very naively to a buttload of redundant IR, to be then pruned and condensed by the backend. This is by design, as it helps keep the frontend as simple and fast as possible, but there are certainly cases where it would be a net benefit to move some of the complexity to rustc in order to lighten LLVM’s workload.
Re: What part of Rust compilation is the bottleneck?
#9One reason for me moving from Rust to Go was compilation speed. Go is a simpler language, so apples to oranges, but Go compiles so fast, which to me makes development very different.
That is definitely true, but from the article it's the backend that takes time, not the frontend where the language itself resides. If you compile go from llvm, it maybe as long as rust.
Re: What part of Rust compilation is the bottleneck?
#10If you make a small change to your application, the Rust compiler does a significant amount of rework. That is, it recompiles a lot of code that it has already compiled before. There are valid technical reasons for this because of how LLVM works or that the linker needs to rewrite all addresses. Yes, incremental compilation is a thing but it’s too coarse IMO. To me it seems that taking an extremely fine grained appro…
Depends on your target; if you have tiny compilation units you won't be able to optimize /inline on a broad target, that's why single unit compilation is an option (that may or may not improve the resut)