Re: Parser Cruft in gram.y

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <kgrittn(at)mail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parser Cruft in gram.y
Date: 2012-12-18 03:19:40
Message-ID: 27090.1355800780@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm frankly kind of shocked at the revelation that the parser is
> already 14% of the backend. I knew it was big; I didn't realize it
> was THAT big.

Yeah, likewise. It makes me wonder whether we aren't past the size
of grammar that bison is a good choice for: considering that gram.y
is only circa 1% of the source text, it's surprising to find that
it compiles to >10% of the object code.

I'm not sure what other tool might be better though. I looked through
http://en.wikipedia.org/wiki/Comparison_of_parser_generators#Deterministic_context-free_languages
but it seems our options are a bit limited if we want something
that produces C. It's not clear to me that any of the likely options
are as mature as bison, let alone likely to substantially outperform it.
(For instance, Hyacc sounded pretty promising until I got to the part
about it doesn't yet support %union or %type.) Still, I didn't spend
much time on this --- maybe somebody else would like to do a bit more
research.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-12-18 03:37:39 Re: Assert for frontend programs?
Previous Message Andrew Dunstan 2012-12-18 03:05:53 Re: configure.in and setproctitle/optreset problem