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

"Gabriel Dos Reis" <gdr@integrable-solutions.net> wrote in message
news:06-08-029@comp.compilers...
> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> | 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++ .


The DMS Software Reengineering Toolkit also uses a GLR parser. It
*does* do full ISO C++, as well as a number of other commercial
dialects (notably GNU and Microsoft in all of its recent
variations). See
http://www.semanticdesigns.com/Products/FrontEnds/CppFrontEnd.html


It builds a parse tree completely independently of resolving symbols
(modulo macro expansion where the macros are not "well-structured" in
thier placement), followed by an attribute-grammar based name and type
resolver. The latter is implemented as a parallel attribute grammar
evaluator, although it gets somewhat less parallelism than we'd like
because of serial dependencies in the name resolution process. (In
contrast, our Java front end for DMS works the same way, and gets a
great deal of parallelism from this).


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


As a general rule, our interest in parsing with DMS is not (yet!) one
in which it is used daily by developers, so we don't focus
specifically on tuning the front ends. Rather, DMS is used to carry
out large-scare analysis and reengineering tasks, which occur less
often and so performance front end isn't as big an issue. Naturally,
we are starting to see applications in which people do want to process
very large source bases with higher frequency, and so we are somewhat
sensitive.


But I don't have any specific performance numbers to offer.
Processing a single, several-thousand line C++ module, however, for an
application we have worked with requires processing several hundred
thousand lines of #includes, and consequently "parsing" such a file
takes tens of seconds.


--
Ira Baxter, CTO
www.semanticdesigns.com

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