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

Gabriel Dos Reis <gdr@integrable-solutions.net>
10 Aug 2006 15:46:50 -0400

          From comp.compilers

Related articles
[7 earlier articles]
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: 10 Aug 2006 15:46:50 -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 06-08-029 06-08-036
Keywords: parse, testing
Posted-Date: 10 Aug 2006 15:46:50 EDT

"Ira Baxter" <idbaxter@semdesigns.com> writes:


[...]


| > It would be interesting to know how Elkhound performs on various
| > projects -- Qt and KDE come to mind.
|
| I don't understand the emphasis on strictly "parsing performance"
| here. Most interesting processing of such files requires the symbol
| table information to be constructed, so it strikes me that the sum of
| lexing/parsing/name resolution is what needs to be optimized.


I agree that name resolution is important in the interesting cases
where the parsing is the focus -- think -fsyntax-only from GCC.
However, in the specific case I worked on, lexing was not an issue
because (and I think it still is not) because the preprocessor is
quite amazingly fast. I believe the combination of lexing/parsing
will not bring new information point for key speed up.


I mentioned Qt and KDE because they are popular, and quite
suprrisingly they exercised weak areas of GCC.


--
                                                                                                              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.