effekt-lang / effekt

A research language with effect handlers and lightweight effect polymorphism

Home Page:https://effekt-lang.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Parser performance: rewrite parser using different combinator library

dvdvgt opened this issue · comments

By investigating the time spent per phase using PR #411, it became apparent that the parser is a major bottleneck of the compiler. The parser regularly occupies more than 50% of the total time spent compiling (for more complex/realistic programs with imports). This offers a massive opportunity for speeding up the compiler.

In my opinion, we have three options here. Use a parser combinator, parser generator library or a completely handwritten parser.

Using a handwritten parser can be a lot of work, and given the experimental stage Effekt is in, also in terms of syntax, it may be hard to make changes to a handwritten parser down the road. After a quick search, I did not find any actively maintained, reasonably popular parser generators for Scala. This leaves us with parser combinators, and there are a few candidates:

  1. https://github.com/j-mie6/Parsley
  2. https://github.com/com-lihaoyi/fastparse

fastparse promises some nice speed-ups.

Minor comment: we do not use scala-parser-combinators but the Kiama library. The thing that I am most afraid of is that we introduce a lot of regressions when it comes to recording source positions on AST nodes.

Thanks, I changed it.

Maybe we should first add some more tests for the parser, so that we can more easily detect regressions.

The problem is the positions which mostly die up in error messages and with LSP. Adding those tests could be a lot of work.