> Re-architecting the rust compiler to be faster is probably not going to happen.
This is a statement without the weight of evidence. The Rust compiler has been continually rearchitected since 1.0, and has doubled its effective performance multiple times since then.
> The second way forward is performing massive changes and/or refactorings to the implementation of the compiler. However, that is of course challenging, for a number of reasons.
> if you change one thing at the “bottom” layer of the compiler, you will then have to go through hundreds of places and fix them up, and also potentially fix many test cases, which can be very time-consuming
> You can try to perform the modifications outside the main compiler tree, but that is almost doomed to fail. Or, you will need to do the migration incrementally, which might require maintaining two separate implementations of the same thing for a long time, which can be exhausting.
> this is a process that takes several years to finish. That’s the scale that we’re dealing with if we would like to perform some massive refactoring of the compiler internals
There are other easier paths to improving the build times for common developer workflows.
The original comment is mostly inline with the article.
All the easy local optimizations have been done. Even mostly straightforward compiler wide changes take a team of people multiple years to land.
Re-architecting the rust compiler to be faster is probably not going to happen.
> Re-architecting the rust compiler to be faster is probably not going to happen.
This is a statement without the weight of evidence. The Rust compiler has been continually rearchitected since 1.0, and has doubled its effective performance multiple times since then.
I'm going off of what is in the article.
> The second way forward is performing massive changes and/or refactorings to the implementation of the compiler. However, that is of course challenging, for a number of reasons.
> if you change one thing at the “bottom” layer of the compiler, you will then have to go through hundreds of places and fix them up, and also potentially fix many test cases, which can be very time-consuming
> You can try to perform the modifications outside the main compiler tree, but that is almost doomed to fail. Or, you will need to do the migration incrementally, which might require maintaining two separate implementations of the same thing for a long time, which can be exhausting.
> this is a process that takes several years to finish. That’s the scale that we’re dealing with if we would like to perform some massive refactoring of the compiler internals
There are other easier paths to improving the build times for common developer workflows.
1 reply →