Re:Rust Analyzer in 2018 and 2019
by matklad on Monday December 17, 2018 @11:55AM
(#18700119)
The thing is, if you target only live editing case, you can become slower for "batch compilation" case. For source browsers this probably isn't too important, b/c one can add caching using something like LSIF. However for command line compilers a similar caching won't work: in the majority of cases, you compile new code. But adding fast "batch mode" on top of "live" editing seems easier than going in the opposite direction.
[ Parent
| on HN ]
How often does one do non-incremental compiles though?
I think it's pretty common for CI, but I guess that use case can handle a little lower performance.
And for each CI compile, how many times have devs done an incremental compile? Probably a lot.
Re:Rust Analyzer in 2018 and 2019
by woolvalley on Tuesday December 18, 2018 @02:09PM
(#18709543)
Well with a good build cache, CI can do things like incremental compiles too. You can even put the cache on the network and have most of your CI use incremental compiles.
I've worked on projects that took over an hour to compile. I would not like lower performance for CI. Many workflows require successful CI runs before one can merge for example.
It's really only Rust and C++ that ever take that long, right? IMO, that's simply the compiler being unacceptably slow. I also can't see a slightly less efficient parse tree being a big factor in compile times this kind of length...