Shahar Soel

> but if I can get 90% there it will make generating a new grammar that much simpler. Yeah it could certainly help, you may want to add some documentation...

UMD: https://github.com/umdjs/umd

See: https://github.com/acornjs/acorn/issues/90

Try out https://benchmarkjs.com/ It was also used in jsperf.com (when it was still working 😢 )

### Outside the box / Feature suggestion This idea may be too much "outside the box" but please hear me out: Perhaps this whole issue would become a-lot less important...

> Removing code blocks from the grammar might also be ok, but inline code blocks are super convenient from a programming-usability standpoint. I don't think they should be eliminated entirely....

Hello. > It will be great to have some performance comparison between OHM, Ometa/JS and custom parsers (such as Esprima). I've authored such a benchmark and while it does not...

Constructing a string matching a grammar is the **other side of the coin** of recognizing a grammar. You generally write a simple recursive interpreter that traverses your grammar structure and...

> I think the question might be a bit more complicated than that. These rules have negative lookaheads and use the stack to match different things from the grammar. Yeah...

> Even without lookaheads and the stack, ordered choice is already really hard. I normally work with LL(K) grammars not PEG, maybe that makes a difference to the complexity? *...