Here is a script that shows the factor of 2 in time taken for parsing. The
idea of the script is to introduce several wrong branches before hitting
the correct one (originally proposed by Guillaume).
[wrongBranches := (25 to: 45) inject: 24 asCharacter asParser into: [:acc
:each | acc / each asCharacter asParser].
rule := PPDelegateParser new.
rule setParser: $a asParser / ((wrongBranches / $. asParser), rule).
rule parse: (String streamContents: [ :s |
30000 timesRepeat: [s nextPut: $.]. s nextPut: $a ])] timeToRun
Below are the graphs that were generated when varying the string length
provided to the above parser description. Green part shows the time taken
by the older version and the red part with the latest PP.
[image: Inline image 2]
Data values and graph generated by the script in the attached file.
On Fri, Jan 30, 2015 at 1:30 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hmm. I thought this was fixed and that you said at the end that the
performance penalty is no longer a factor of 2.
Do you have a simple example for checking the simple case of 2x
On Fri, Jan 30, 2015 at 12:28 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
> Since the work on the integration of PPContext in PetitParser, there is
> significant performance degradation. I have already mentioned that on
> simple grammar the factor is about 2. But on complex grammar (for example,
> our proprietary parser for 4D language ), we have seen that degradation is
> goes well beyond this factor. So, for example, for 800K lines that we parse
> in under 10 minutes without PPContext work, with the latest version it goes
> beyond 2h.
> I have not been able to reproduce my case on simple grammars. May be we
> can have some benchmarks using open source parsers and large code bases
> (e.g. PP Java Parser on JHotDraw or ArgoUML).
> Currently, I circumvent this issue by using PP v1.51 but I can provide
> relevant feedback and run benches on any improvements.
> Moose-dev mailing list
"Every thing has its own flow"
Moose-dev mailing list