Re: Parser performance, was What is the future of Compiler technology?

Gabriel Dos Reis <gdr@integrable-solutions.net>
5 Aug 2006 21:55:41 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: What is the future of Compiler technology? Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2006-07-16)
Re: What is the future of Compiler technology? pocmatos@gmail.com (Paulo Matos) (2006-07-31)
Re: What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-07-31)
Re: Parser performance, was What is the future of Compiler technology? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-08-03)
Re: Parser performance, was What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-08-04)
Re: Parser performance, was What is the future of Compiler technology? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-08-05)
Re: Parser performance, was What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-08-05)
Re: Parser performance, was What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-08-06)
Re: Parser performance, was What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-08-06)
Re: Parser performance, was What is the future of Compiler technology? idbaxter@semdesigns.com (Ira Baxter) (2006-08-08)
Re: Parser performance, was What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-08-10)
| List of all articles for this month |

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
Newsgroups: comp.compilers
Date: 5 Aug 2006 21:55:41 -0400
Organization: Integrable Solutions
References: 06-06-044 06-06-055 06-07-023 06-07-031 06-07-109 06-07-114 06-08-013 06-08-019
Keywords: parse, performance
Posted-Date: 05 Aug 2006 21:55:41 EDT

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:


[...]


| [Ah, that makes more sense, it's the symbol table management.


That was the part I worked on. It was only one aspect of the issue;
Mark Mitchell worked on other facets, such as better data structures
for parsing declarators, better caching of class-scope symbols, etc.


| Other than rewriting the symbol table to be faster, is there any way
| to address this in the parser, e.g., batch the lookups somehow, or
| parse somehow that is less dependent on name semantics? -John]


The latest, publically documented, alternative attempt I know of is
from Scott Pike with his generalized parser (found in Elkhound).
However, I don't think it parses full ISO C++ (at least the standard
library implementation that comes with GCC). Elkhound "forks" at
ambiguity points and postpone ambiguity resolution to later phases.
That also means keeping around potentially uninteresting parse trees,
a source of potential inefficiency -- however, proper measurements
need to be done instead of speculation. It would be interesting to
know how Elkhound performs on various projects -- Qt and KDE come to
mind.


--
                                                                                                              Gabriel Dos Reis
                                                                                      gdr@integrable-solutions.net


Post a followup to this message

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