3 ms·
From the post: > However, at this point the compiler has been heavily optimized and new improvements are hard to find. There is no low-hanging fruit remaining.
by PoignardAzur 3y ago
From the post:
> However, at this point the compiler has been heavily optimized and new improvements are hard to find. There is no low-hanging fruit remaining. But there is one piece of large but high-hanging fruit: parallelism.
From discussions I've seen, there's not much high-hanging fruit left either, short of rewriting the entire compiler for better incremental compilation.
- insanitybit 3y agoI think if you're talking about the compiler getting faster at what it does today, how it does it today, that's true. But that's a heavy constraint. If we got support for binary dependencies, that wouldn't be a compiler optimization in the same sense as parallelism is, but it would radically improve compile times for the average project.
- PoignardAzur 3y agoYeah, but binary dependencies or watt-style precompiled macros aren't going to get improve the build times people really care about, incremental build times. The parallel frontend is the plausibly the last major improvement we'll see on that front for years. Incremental matters more than clean build times because (A) you're likely to do a lot more of them (B) they break developer flow more than waiting on CI does (C) at least in theory, you can always add more cores to your CI and get reasonable speedups, less so for incremental.
- insanitybit 3y ago> Yeah, but binary dependencies or watt-style precompiled macros aren't going to get improve the build times people really care about, incremental build times. Why not? If I add a new struct with `#[derive(serde::Serialize)]` I'll benefit from serde being compiled with optimizations. > they break developer flow more than waiting on CI does Eh, depends.