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

Hans-Peter Diettrich <DrDiettrich1@aol.com>
3 Aug 2006 11:03:22 -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)
[1 later articles]
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: 3 Aug 2006 11:03:22 -0400
Organization: Compilers Central
References: 06-06-044 06-06-055 06-07-023 06-07-031 06-07-109 06-07-114
Keywords: parse, performance

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.


Did somebody ever create an "stripped" preprocessed source file, from a
C/C++ source file, with all #includes and macro invocations expanded,
and all unused declarations removed? It were interesting to compare the
compile time of such an preprocessed file, against the compile time of
the raw source file.


Perhaps windows.h is an extreme example, because it adds more than 2 MB
to an preprocessed source file. Comments and #if's properly removed,
only file and line information retained! Now consider the impact of the
memory allocations, resulting from that amount of text, and the growth
of the symbol and other tables, possibly slowing down the further
processing of the text.


I also don't know what impact namespaces have on the compilation of such
an source text. Even if namespaces can be selectively included or
excluded from the symbol tables, I'm not sure how the tables for such an
namespace actually are created. How does a compiler know, which sources
to inspect for contributions to an namespace?


DoDi


Post a followup to this message

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