Peg only mode?

[andrewchambers]

I was benchmarking leg vs packcc for https://github.com/andrewchambers/minias and saw that leg is both 10x faster and uses 10x less ram for my examples - I think in many cases the overhead of packrat parsing might not be worth it.

I was wondering if there is any chance for a peg only mode or peg only port, as packcc has many other advantages over peg/leg.

[arithy]

Thanks for sharing the performance results.
I guess the performance benefit brought by packrat parsing cannot be gained for too simple grammar like that of the assembly language.

Unfortunately, packrat parsing is essential for PackCC, because one of the most beneficial features of PackCC is left-recursive grammar rule support, which cannot be realized without packrat parsing.
I don't want this feature to be inactive anytime.

Moreover, I'm not motivated to make PackCC implementation more complicated by dual algorithms.

[andrewchambers]

@arithy No problem.

I think some things in packcc could be improved by some benchmarking regardless, for example:

If i repeatedly called the parser like in the calculator example, 90 percent of the cpu time was spent in memmove shifting the packcc arrays, I wondered if there might be a simple solution for such cases and if my result was actually just something easily fixed.

[arithy]

Thanks for the valuable information.
I'll analyze the performance issue especially regarding array operations.
It would be very helpful if you could share some test PEG file with me.

P.S. Your requests and suggestions will be welcome from now on, too.

[dolik-rce]

Just to make sure: Are you talking about the performance of grammar parsing or of the generated code parsing the assembler?

If it is about the generated code, then I have done some analysis in the past. It turns out a lot of time is wasted in memory allocations for each rule. Some details can be found in universal-ctags/ctags#2878. There are two possible approaches: either reduce number of rules (could be done automatically when generating the code) or use better allocator. Actually both could be useful at the same time. I have started working on this with promising results, but ever finished. I can push the code, if anyone is interested in the work in progress.

[andrewchambers]

I will make an issue with an example.

[arithy]

@dolik-rce, thanks for informing me of your activity on performance improvement.
It's very interesting. I'd like to see your code even in progress.

[andrewchambers]

I created #47 which shows how the parser performance differs greatly when using in two slightly different ways.

[arithy]

@andrewchambers, thanks a lot!
I recognized it is a more critical issue than I thought.

[andrewchambers]

@arithy I think even the fast case in my example is slower than expected - 1 second for 100k lines seems fairly slow - I think leg was 100x this speed and so was gnu as.