3 ms·
1 - Python parser generators often are a bunch of .py files, so you won't get anything external 2 - With PLY ( and some others) you can use any non-terminal as
by alexk 18y ago
1 - Python parser generators often are a bunch of .py files, so you won't get anything external
2 - With PLY ( and some others) you can use any non-terminal as the start in the test mode, and it won't make any impact on the performance
4 - in case of python based parser generators - lexer is a weak part. Take PLY - it's lexer is based on re module, so you wont gain much here, you can write manual lexer and boost your performance.
- briansmith 18y ago1. That is typically the case with parser generators. But, it is still a build-time dependency. Right now I don't really have any build-time processing except for unit tests and I want to keep "building" as simple as possible. 2. That is good to know. That indicates to me that PLY doesn't do a lot of optimizations, but maybe the optimizations that I am used to having for LL(k) parsing are not effective or necessary for (LA)LR parsing. 4. That indicates to me that the performance won't be any better than the re-only approach. What isn't shown is that I compile the "iri" and "iri-reference" regexes into two big regular expressions. AFAICT, matching one match for a big regular expression instead of a series of matches of small regular expressions will always be faster, especially if the RE engine does any (global) optimizations. By the way, an IRI is a single token in my application so my parser is really just a lexer.