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

Gabriel Dos Reis <gdr@integrable-solutions.net>
4 Aug 2006 16:37:04 -0400

          From comp.compilers

Related articles
What is the future of Compiler ? blertadn@yahoo.com (blerta bishaj) (2006-06-12)
Re: What is the future of Compiler technology? tommy.thorn@gmail.com (Tommy Thorn) (2006-06-19)
Re: What is the future of Compiler technology? oliver@zeigermann.de (Oliver Zeigermann) (2006-07-16)
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: 4 Aug 2006 16:37:04 -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
Keywords: parse, GCC, performance

Hans-Peter Diettrich <DrDiettrich1@aol.com> writes:


| Gabriel Dos Reis schrieb:
|
| > From experience, the performance of the GCC/g++ *parser* had worried
| > and continue to worry users and corporate that base their system
| > compilers on it.
|
| IMO it's neither the parser nor the lexer, instead it's the time spent
| in preprocessing the source files.


Having spent time on the matter, and having seen fellow contributors
work on improving the situation, I have to disagree.


[...]


| I also don't know what impact namespaces have on the compilation of such
| an source text.


Basically, one has to do some minimal lookup to parse C++,
i.e. distinguish between type-names, template-names, namespace-names,
and other kind of names. The elaborated name lookup rules (partly
introduced by namespaces) compounds the issue. From my measurements,
non-negligible amount of time taken by the parser can be credited to
name lookup. Of course, since (partial) template instantiation is
needed by the parser by logical implication, the issue is not as
simple as often stated in traditional textbooks.




--
                                                                                                              Gabriel Dos Reis
                                                                                      gdr@integrable-solutions.net
[Ah, that makes more sense, it's the symbol table management. 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]





Post a followup to this message

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