Re: Recursive Descent Parsers and YACC

melling@psuvax1.cs.psu.edu (Michael D Mellinger)
Mon, 26 Nov 90 00:08:42 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: Recursive Descent Parsers and YACC hankd@ecn.purdue.edu (1990-11-17)
Re: Recursive Descent Parsers and YACC henry@zoo.toronto.edu (1990-11-17)
Re: Recursive Descent Parsers and YACC mailrus!sharkey!hela!iti.org!dhw@uunet.UU.NETid AA (1990-11-20)
Recursive Descent Parsers and YACC grosch@gmdka.uucp (Josef Grosch) (1990-11-22)
Re: Recursive Descent Parsers and YACC grimlok@hubcap.clemson.edu (1990-11-23)
Recursive Descent Parsers and YACC jsp@milton.u.washington.edu (Jeff Prothero) (1990-11-23)
Re: Recursive Descent Parsers and YACC melling@psuvax1.cs.psu.edu (1990-11-26)
Re: Recursive Descent Parsers and YACC moss@cs.umass.edu (1990-11-26)
Re: Recursive Descent Parsers and YACC aycock@cpsc.ucalgary.ca (1990-11-26)
| List of all articles for this month |

Newsgroups: comp.compilers
From: melling@psuvax1.cs.psu.edu (Michael D Mellinger)
In-Reply-To: grosch@gmdka.uucp's message of 22 Nov 90 14:47:29 GMT
Keywords: parse, performance, gcc, yacc
Organization: Penn State Computer Science
References: <9011221247.AA18998@gmdka.uucp>
Date: Mon, 26 Nov 90 00:08:42 GMT

In article <9011221247.AA18998@gmdka.uucp> grosch@gmdka.uucp (Josef Grosch) writes:
> Pure parsing can be made faster by a factor of 2, 3, or more compared to
> Yacc. However, as pure parsing takes only 5 to 10 % of the whole
> compilation time, it is not the bottle neck and does not matter too much.
> Scanning is much more time critical, as it takes 30 to 50 %. Therefore Lex
> can not be used for high speed compilers. Scanner generators like Rex and
> flex are up to 5 times faster.


I have been playing around with gcc (the NeXT Objective C version) and have
found that by giving a -Q command-line option gcc will tell you how much
time it spends in each section of compilation. Without optimization turned
on, it seems to spend most its time parsing code. gcc doesn't use Lex, and
it is still much slower than Turbo C or Think C. Here is the result of
compiling a 149 line program. I would like to speed GCC up. Bison is used
when compiling GCC and not YACC. Would switching to another parsing tool
give me the speed-up I desire? A FAST FREE compiler would sure complement a
FREE, slow optimizing compiler. Besides gcc is the fastest compiler
available for the NeXT.


-Mike


handel> cc -Q -c CardDrawView.m
  _1_CardDrawView _2_CardDrawView _3_CardDrawView _4_CardDrawView
time in parse: 5.939384
time in integration: 0.000000
time in jump: 0.000000
time in cse: 0.000000
time in loop: 0.000000
time in flow: 0.188038
time in combine: 0.000000
time in local-alloc: 0.000000
time in global-alloc: 0.246630
time in final: 0.168993
time in varconst: 0.281626
time in symout: 0.000000
time in dump: 0.000000


handel> wc CardDrawView.m
          149 249 2690 CardDrawView.m
[I suspect that there is considerably more time spent passing code through
the assembler and linker than is spent by yacc. Keep in mind that the yacc
code switches out to action routines that build parse trees and symbol tables,
and such routines will be present no matter how you parse. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.