Why not just use antlr to impl the interpretor?

[YuyuZha0]

I found currently it's a handwriting parser

[jasmith-hs]

One reason would be because it's likely much slower, see:

Antlr is now down to being only ~4 times slower than the handwritten parser.

antlr/antlr4#1540

---

if you want the absolute best performance you may want to opt for a custom parser

https://tomassetti.me/improving-the-performance-of-an-antlr-parser/

---

They helped me realize that parsing is not magic, and if you have performance issues with ANTLR, you can actually write a decent parser for any sensible language by hand.

https://groups.google.com/g/antlr-discussion/c/74aPR8wjXe4

We care a lot about performance as we use Jinjava to server-side render pages for HubSpot's CMS.

[YuyuZha0]

Make sense, thanks!

[YuyuZha0]

I'm still a little bit curious that, if ANTLR is slow, it should be considered as a compile time behavior and should impact on the bootstrap time, not the runtime performance, or the Jinjava itself do not have a "compiled" stage, and everything is rendered by interpretation?

[YuyuZha0]

I mean, parsing should be a one time effort, after that, the AST could be reused for further rendering, just like what the java.util.regex.Pattern did.

[jasmith-hs]

Jinjava does have a compiling stage, but we need that to be fast because we parsed from string templates and use them a single time while that AST is in memory very often. Sometimes we reuse the parsed AST over-and-over, but most jinjava usage is parse and immediately interpret so we need that to be fast