" Libmarpa takes less than 10% of the time, so a 10% change in its speed is a 1% change in the overall result, which on Linux I do not think is measureable."
Well isn't this a big problem? From my basic understanding, it seems that libmarpa does all the heavy lifting parsing-wise (for grammars without Perl semantic actions). So 90% is lost in "cosmetic" overheads (such as compiling SLIF down to a libmarpa-compatible grammar object, doing passes back-and-forth through XS and maybe doing the recognizer traversal). Would this 1:9 ratio change if a single grammar is provided with a vast set of parse inputs? E.g. process 10,000 strings in a single pass, so that the initialization overhead melts down. I could of course be off my guess, and the 90% overhead is not mostly in initialization but in some other parts of the processing that I am currently falsely assuming to be done in libmarpa. But making the 10% to 90% statement certainly makes Perl look bad in this case (and alerts my curiosity as to why that's the case). Deyan On Wed, Jan 15, 2014 at 10:45 PM, Ron Savage <[email protected]> wrote: > Well done! This sounds like a big win, and having the nerve to make > significant changes like this is usually the sign of a great programmer. > > It means something else, of course, for those people who just change > things to fabricate the impression that they are 'doing something. > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
