4 ms·
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
by matklad 8y ago
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.
- nicoburns 8y agoHow often does one do non-incremental compiles though?
- losvedir 8y agoI think it's pretty common for CI, but I guess that use case can handle a little lower performance.
- smaddox 8y agoAnd for each CI compile, how many times have devs done an incremental compile? Probably a lot.
- adrianN 8y agoI'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.
- nicoburns 8y agoIt'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...
- woolvalley 8y agoWell 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.