4 ms·

> you probably meant “25% of a lot is still a lot” Yeah exactly. This was afaik a fairy small sized application (where the majority was probably framework code

by klabb3 3y ago

> you probably meant “25% of a lot is still a lot” Yeah exactly. This was afaik a fairy small sized application (where the majority was probably framework code) which went from 20s to 5s for incremental compilation on a very beefy desktop rig. Those absolute numbers are important to grok the situation. > That is a pretty fantastic improvement, considering the whole year improvements in the last 4 years have been 7%, 17%, 13% and 15%, for an overall speed gain of 37%. > If all of this doesn’t sound impressive, I’d encourage you to read nnethercote’s annual reports which explain how much effort went into making compile times faster It’s not at all that it’s unimpressive. It’s abundantly clear that extremely bright minds are putting a ton of effort into it, consistently and over time. I’ve worked personally with some of these people and they are insanely talented and knowledgeable… Which is precisely why I’m concerned that we’re not seeing the big boosts that comes with picking low hanging fruit, perhaps there isn’t any left. Optimization tends to yield lower results over time (although the recent advances are great to see and I wish it continues). From the outside though, it appears like either inherent constraints that limit how far you can go, or at least initial compiler design reasons that would be cost-prohibitive to change.

nindalf 3y ago
> big boosts that comes with picking low hanging fruit, perhaps there isn’t any left. Optimization tends to yield lower results over time As the link I shared says > For the first time ever, I’m writing one of these posts without having made any improvements to compile speed myself. I have always used a profile-driven optimization strategy, and the profiles you get when you measure rustc these days are incredibly flat. It’s hard to find improvements when the hottest functions only account for 1% or 2% of execution time. Because of this I have been working on things unrelated to compile speed. > That doesn’t mean there are no speed improvements left to be made, as the previous section shows. But they are much harder to find, and often require domain-specific insights that are hard to get when fishing around with a general-purpose profiler. And there is always other useful work to be done. --- > From the outside though, it appears like either inherent constraints that limit how far you can go, or at least initial compiler design reasons that would be cost-prohibitive to change. Also correct. Rust prioritised faster run time over fast compilation times. For example, monomorphization is something used pervasively in most Rust code. Fast at run time, but slow to compile. The fact that the entire crate needs to be compiled if a line is changed is yet another issue. Everything indicates that even if Rust improves, it will never reach that 2 second recompile for large projects. But fortunately the experience of the last few years suggests that it's still possible to succeed despite (or maybe because of) prioritising runtime over compile time.

by klabb3 3y ago

nindalf 3y ago

> big boosts that comes with picking low hanging fruit, perhaps there isn’t any left. Optimization tends to yield lower results over time As the link I shared says > For the first time ever, I’m writing one of these posts without having made any improvements to compile speed myself. I have always used a profile-driven optimization strategy, and the profiles you get when you measure rustc these days are incredibly flat. It’s hard to find improvements when the hottest functions only account for 1% or 2% of execution time. Because of this I have been working on things unrelated to compile speed. > That doesn’t mean there are no speed improvements left to be made, as the previous section shows. But they are much harder to find, and often require domain-specific insights that are hard to get when fishing around with a general-purpose profiler. And there is always other useful work to be done. --- > From the outside though, it appears like either inherent constraints that limit how far you can go, or at least initial compiler design reasons that would be cost-prohibitive to change. Also correct. Rust prioritised faster run time over fast compilation times. For example, monomorphization is something used pervasively in most Rust code. Fast at run time, but slow to compile. The fact that the entire crate needs to be compiled if a line is changed is yet another issue. Everything indicates that even if Rust improves, it will never reach that 2 second recompile for large projects. But fortunately the experience of the last few years suggests that it's still possible to succeed despite (or maybe because of) prioritising runtime over compile time.