|RE: Partially handwritten parsers email@example.com (Quinn Tyler Jackson) (2009-06-01)|
|RE: Partially handwritten parsers firstname.lastname@example.org (Lowell Thomas) (2009-06-19)|
|From:||"Lowell Thomas" <email@example.com>|
|Date:||Fri, 19 Jun 2009 11:19:09 -0400|
|Posted-Date:||21 Jun 2009 16:50:08 EDT|
>[How often is the parser a significant part of a program's runtime? The
>scanner is usually much slower. -John]
The tests that I have been doing use scannerless parsing but the larger
issue you are raising, that parsing is often not the bottleneck of the
application, is no doubt valid. But being relatively new to the business, my
motivation for building a better mousetrap is still a natural curiosity.
Quinn Tyler Jackson wrote:
>Before descending into a rule, first peek ahead one character to see if a
>match is even possible.
>OK, now my point: in a generated parser, these look aheads can be generated
>based on the grammar.
Thanks for your comments. Just googling up "Adapting to Babel" has given me
much to chew on. But just to comment on your look ahead idea, actually I
tried this in an earlier version, using compile-time-generated predictive
parsing tables. It did lead to improved parsing time factors of 2-4 (mostly
2). Nice, but not the kind of improvement I was hoping for.
If anyone is interested, you can take a look or try it yourself. It also has
some new features for AST construction and traversal and some improved
tracing/debugging features. Its free (GLP) and available as APG Version 6.0
from my website.
Return to the
Search the comp.compilers archives again.