skip parser option?

[ghnatiuk]

Since the parser layer of gherkin exists solely to determine if the order of events is valid and provide useful messages when it's not, what about an option (mike suggested --unpickled) that skips the parser and sends the lexer events directly to cucumber?

This could provide a speed benefit for running large suites of features that are relatively stable and known to have proper syntax, with the caveat that parsing/lexing error messages may not be very useful.

I think it would make sense when working on writing a new feature to have it pass through the parser to ensure validity, but when running rake cucumber to skip the parsing step (or at least have the option to). It's superfluous and adds overhead for a well-written feature.

WDYT? One more item to consider for performance enhancement, I suppose.

[aslakhellesoy]

This would definitely speed things up, but wasn't the Ragel lexer able to do this at some point? I don't remember the exact reason for writing a hand-written parser (we've talked about it before and I have forgotten). Wasn't it to open up for slightly different grammars like JBehave? Since I don't care so much about JBehave anymore I don't think we need more than one grammar.

Would it be possible to ditch the transition table based parser altogether and have Ragel do all the validation work?

[msassak]

We were doing that in Ragel, but abandoned it for increased testability and flexibility. Introducing that seam for testing made a big difference in ease of development. I think all the talk of speeding things up is a waste of time right now because a) Gherkin doesn't even work with Cucumber yet, despite it being 40x faster than Treetop, and b) we haven't measured anything. The only truly slow part of Gherkin seems to be the C extension on 1.9, which for some reason is much slower than the C extension on 1.8.x, though still faster than Treetop.

[msassak]

Also, I forgot that we are using the flexibility for the steps parser.

[aslakhellesoy]

Thanks for the recap Mike. Let's revisit this after Cucumber integration.

[aslakhellesoy]

Closing this, since it doesn't seem to have significant impact on performance.