You don't have to guess! We included our original spark.py-based MOSDEF in the MOSDEF 2.0 tarball. So you can do pretty detailed performance characterizations on a real world, complex parser. In our testing ,it's basically "twice as fast" but YMMV! :>
The other major disadvantage with spark.py was the way it used the stack. A long assembly file (in our case) would exhaust the stack limits very quickly. PLY removed this limitation for us. If you're interested in PLY and parsing speed, then I highly encourage you to look at the MOSDEF package and how it uses PLY. -dave On Feb 13, 11:48 am, eliben <[email protected]> wrote: > On Feb 13, 6:15 pm, David Beazley <[email protected]> wrote: > > > SPARK, developed by John Aycock, precedes PLY by at least a > > couple of years. I had seen John present work on SPARK at > > several Python Conferences in the late 90's and thought the > > introspection approach he used was pretty slick. So, I copied > > it when I created PLY several years later. > > Thanks, it's interesting to know the history :-) > > > I didn't use SPARK because I wanted something based on > > LR parsing like traditional yacc (SPARK uses the Earley parsing > > algorithm which is more powerful, but not as fast). > > Yes, I imagine Spark should be much slower, both because the table- > based approach of PLY and the pre-generation of parsing tables that > doesn't require to "understand" the grammar each time a parser is > executed (this takes long for large grammars) > > On the other hand, its source code is delightfully short and simple. > ~800 LOC for a lexer, parser, and AST traversal, wow! > > Eli --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ply-hack" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/ply-hack?hl=en -~----------~----~----~----~------~----~------~--~---
