Maybe you could scan individual characters and put more of the
complexity in the parser instead. For instance, using ? to optionally scan
for something could possibly be changed to a parsing rule. In general,
you could reduce the complexity in the scanner and move it to the parser.
Dennis
brock wrote:
> Hi, I've run into this problem using ply-2.5 (originally) and just
> reproduced it on ply-3.0.
>
> I've got a grammer (i'll add it below) for which lexing time seems to
> grow exponentially in the length of a single string. Since I don't
> think, that was very clear, let me give concrete examples and timing.
> The lexing is buried inside a larger program, so there is some
> overhead, but it exits as soon as the lexing is complete.
>
> Time Length of String String
> 0.18s 1 a
> 0.19s 5 abcde
> 0.22s 10 abcdefghij
> 0.74s 13 abcdefghijklm
> 1.86s 14 abcdefghijklmn
> 5.26s 15 abcdefghijklmno
>
> My lexing rules are (in priority order):
> r'([pP]([kK]([gG][sS]?)?)?)?<'
> r'>'
> r'(\:?[^\(\s\:]?[^\s\:]*)*\:'
> r'[^\s\(\'\"][^\s\*]*[^\s\)\'\"\>] | [^\s\(\)\'\"]'
> t_LPAREN = r'\('
> t_RPAREN = r'\)'
> t_QUOTE1 = r'[\']'
> t_QUOTE2 = r'[\"]'
> t_ignore = r' '
>
> It's been a long time since I've written lex stuff, so maybe I'm
> making an obvious mistake with my lexing strings, but it still seems
> like this shouldn't be happening. Any help or guidance would be
> appreciated as I really like ply, but this performance trend is a real
> problem.
>
> Thanks,
> Brock
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
