4 ms·
I feel like the breakdown in problems should include real world data to back it up. Hopefully future articles will do so. In particular, people like to put bla
by epage 7y ago
I feel like the breakdown in problems should include real world data to back it up. Hopefully future articles will do so. In particular, people like to put blame on the borrow checker when I thought it wasn't all that bad. From my understanding, the worst offenders are LLVM (because rustc is using it in a way that they haven't optimized for) and linking (which there are experiments with using lld which people report huge gains with.
Besides the tone, my main gripe with the article and some discussions I've seen elsewhere is mixing implementation trade offs with design trade offs. For example, LLVM and not doing your own optimization passes can be important for time-to-market. The only reasonable alternative that I can think of without sacrificing time-to-market is between LLVM or a C backend. Delaying Rust would have made it irrelevant.
Now for some context for those not as familiar with Rust:
> Stack unwinding — stack unwinding after unrecoverable exceptions traverses the callstack backwards and runs cleanup code. It requires lots of compile-time book-keeping and code generation.
This is for asserts (panics) and can be toggled with a flag. It isn't inherent to the language though some older code uses it extensively (like rustc) because it predates the current language design (from what I've read).
> Tests next to code — Rust encourages tests to reside in the same codebase as the code they are testing. With Rust's compilation model, this requires compiling and linking that code twice, which is expensive, particularly for large crates.
This is in a list of negative impacts of features but people outside of Rust reading this might not catch the why this is done. Tests inline to your code have access to your private interfaces. External tests are for integration testing and build against your library like anyone else would.
- gameswithgo 7y agoThe worst offenders vary a lot by particular codebase. I had a crate where the compile times were bad due to trait bounds. I was able to refactor to drop times from ~2 minutes to ~6seconds! That should'nt have been necessary for me to refactor though. Sometimes its llvm, sometimes its rust macros encouraging HUGE functions which then leads to slow llvm optimizations. Sometimes it's large use of generics. Sometimes it is the linker. There are various ways to hit slow compile times.
- rhn_mk1 7y agoHow did you figure out what was responsible for the slowness?
- gpderetta 7y agoIf it is even remotely like C++, most of the time will be spent on template instantiation, for template heavy projects, and linking. Linking is even slower for template heavy code because it tends to generate a lot of extremely long symbols to the point that release builds are often faster to build because they get rid a lot of functions.
- umanwizard 7y agoRust does not have C++-style templates.
- MaulingMonkey 7y agoRust generics are sanely statically typed instead of duck typed, so parsing should be cheaper, but they can still cause duplicate codegen that the optimizer then needs to sift through and deduplicate, optimize, etc.
- umanwizard 7y agoSorry, I didn’t mean to imply that Rust’s generics don’t slow down compilation at all. They surely do, as does any form of code generation. My bad for not being more clear — I just wanted to point out that Rust doesn’t have anything like the full, accidentally Turing complete template metalanguage that C++ has.
- terminaljunkid 7y agoAt the point, all that matters is if templates are monomorphized or not. Other things don't affect much. Your previous statement just counts like fanboy-ism.
- adev_ 7y ago> My bad for not being more clear — I just wanted to point out that Rust doesn’t have anything like the full, accidentally Turing complete template metalanguage that C++ has. That's irrelevant. Being Turing complete does not mean being slow. Having template with duck typing does not imply being slow. That's completely irrelevant and pretty fanboy. The main reason C++ template are slow to compile is that they have to be header-based..... Meaning parsed again and again and again in every translation unit. Which is by itself pretty insane, and when you realize that, you realize that C++ compilers are in fact pretty fast compare to the job they do. Ideally c++ modules might solve that on the long term.