Mike Lischke

The root cause should be removed instead of all these workarounds. In my [next generation ANTLR project](https://github.com/mike-lischke/ANTLRng) I plan to convert the recursive prediction code to become iterative and add...

> Preliminary benchmark results on a i7-7820HQ - 32GB The JS results are taken with `measureTime`, as kotlinx-benchmark for JS is blocked by [Kotlin/kotlinx-benchmark#185](https://github.com/Kotlin/kotlinx-benchmark/issues/185) > > File JS JVM >...

> I think on K/JS the major performance issue is the use of a string for the generated ATN, which must then be converted to a char array, and decoded...

> > The root cause should be removed instead of all these workarounds. In my [next generation ANTLR project](https://github.com/mike-lischke/ANTLRng) I plan to convert the recursive prediction code to become iterative...

> True, unfortunately JVM can't handle huge arrays unlike other runtimes out of box. Really? You can just allocate an array up to 2^31 entries (more than enough for the...

> I've removed all parse error catching, so if it fails it's unrecoverable, and I've not encountered any failures (apart from the stack overflow). You mean all catch clauses in...

Interesting numbers! If you could add C++ and C# (and maybe Go) too this would be the long awaited performance comparison chart for the ANTLR runtimes :-) Can you explain...

OK, thanks, that explains the good performance. Since Kotlin itself compiles to WASM, it makes no difference for the developer who's working with Kotlin code. However a, say, C++ developer,...

IIUC the generated parsers, lexers, visitors and listeners are also part of the WASM binary, correct? If so that would be contrary to the idea of having these files in...

Got exactly the same build error. Is anyone looking into such issues actually?