4 ms·
The article makes me wonder: how much headroom do compilers of newer slow-to-compile languages such as Rust or Swift have for improving compile times?
by tayistay 5y ago
The article makes me wonder: how much headroom do compilers of newer slow-to-compile languages such as Rust or Swift have for improving compile times?
- yoz-y 5y agoSwift can reduce the “max time to compile a complex expression” indefinitely to force programmers to write simpler-to-compile code. /s
- adrianN 5y agoNicholas Nethercote has a series of blog post on speeding up the Rust compiler. [1] There are (were?) also efforts going to to reduce the amount of LLVM work by shifting some of that work further up in the stack. [1] https://blog.mozilla.org/nnethercote/author/nnethercotemozillacom/ https://blog.mozilla.org/nnethercote/author/nnethercotemozil...
- the_duke 5y agoIn addition to the mentioned micro optimizations, I'll add some possibilities from the Rust angle. Rust has really impressive incremental compilation built in already. The first compile is annoyingly slow, but additional ones will be surprisingly fast, often finishing in a second or two , even in larger code bases. Especially if you split up your own code into multiple crates. This could further be significantly improved by a demonized compiler that keeps everything in memory. Additionally there could be a way to share compilation artifacts via the package registry, also making first time compiles fast. There is also an effort to use Cranelift as a codegen backend, which can be faster than llvm for debug builds, and has the potential for JIT compiling functions on first use, which would make debug builds a lot faster again as well. Zig also has some really cool plans in this domain. There is lots of headroom to make compiling these static languages faster, but compilers would often need to be (re)written from scratch with these compilation strategies in mind.