Re: What is the future of Compiler technology?

=?ISO-8859-1?Q?J=FCrgen_Kahrs?= <Juergen.Kahrs@vr-web.de>
3 Aug 2006 11:02:58 -0400

          From comp.compilers

Related articles
[5 earlier articles]
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? eliotm@pacbell.net (Eliot Miranda) (2006-07-19)
Re: What is the future of Compiler technology? Colin_Paul_Gloster@ACM.org (Colin Paul Gloster) (2006-07-19)
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: What is the future of Compiler technology? Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2006-08-03)
Re: What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-08-04)
Re: What is the future of Compiler technology? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-08-05)
| List of all articles for this month |

From: =?ISO-8859-1?Q?J=FCrgen_Kahrs?= <Juergen.Kahrs@vr-web.de>
Newsgroups: comp.compilers
Date: 3 Aug 2006 11:02:58 -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 wrote:


> | [I don't think I've ever seen an application where the parser took
> | enough time to worry about. Lexer performance is much more important
> | since the lexer is the only part of the compiler that has to look at
> | each character of the input program. -John]
>
> 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.


Remember how this thread started.
We were actually talking about generated parsers.


> Jürgen Kahrs wrote:
>> > Oliver Zeigermann wrote:
>> >
>>> > > your "ordinary" programmer. This requires compiler generators to be
>>> > > easier to use and understand. Who *really* understands yacc?
>> >
>> > We already _have_ compiler generators which are easier to understand
>> > than yacc. Look at CoCo/R. Many others are available.
>
> Do you know if there are any studies on the performance of the
> resulting parser in C++ against 'traditional' tools? (There are
> probably many studies...)


The focus was on parsers which are generated and readable. A parser
generated by CoCo/R initially only _parses_ some text and does it
blazingly fast. Performance is _never_ an issue. But when you do more
than just syntax-guided parsing (like saving context, generating
code), than performance may be an issue. But this is not about parsing
performance anymore.



Post a followup to this message

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