▲ | adev_ 3 days ago | |||||||
> No, the problem for a language server is incremental performance, not batch performance "When something is fast enough, people start to use it differently" - Linus Torvalds. Make your parser able to parse the current file at 30FPS and you do not need incremental parsing anymore nor error recovery. That is probably part of the idea here. | ||||||||
▲ | dzaima 3 days ago | parent | next [-] | |||||||
Here that can go both ways - SIMD parsing can allow handling arbitrary changes in reasonable time for files below like maybe 100MB (i.e. everything non-insane), whereas incremental parsing can allow handling small changes in truly-arbitrary-size files in microseconds. A trade-off between better average-case and worst-case time. (of course the ideal thing would be both, but that's even more non-trivial) | ||||||||
▲ | awson 2 days ago | parent | prev | next [-] | |||||||
Absolutely. Quite a long time ago I was working on a some business application's reporting facility. It used to take about an hour, and my development reduced this time to a 1 or 2 seconds ballpark. This was HUGE. And changed the way users create these reports forever. | ||||||||
▲ | seanmcdirmid 2 days ago | parent | prev [-] | |||||||
It’s not good enough. Incremental parsers can save trees across edits, and you can hang type information off of those trees, so you just aren’t saving parsing time, you are saving type checking time as well. Even if you have a super fast batch parser, you are screwing yourself in other areas that are actually much more expensive. | ||||||||
|