This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [gcjx] Patch: FYI: parser and lexer changes
- From: Tom Tromey <tromey at redhat dot com>
- To: Ranjit Mathew <rmathew at gmail dot com>
- Cc: GCJ Patches <java-patches at gcc dot gnu dot org>
- Date: 03 Oct 2005 21:00:18 -0600
- Subject: Re: [gcjx] Patch: FYI: parser and lexer changes
- References: <m3br26l4j8.fsf@localhost.localdomain><4341EDBC.1020203@gmail.com>
- Reply-to: tromey at redhat dot com
Ranjit> You call a 30% speedup not good enough? Whoa!
I hate to say this, since I think it is a transient condition, and I
don't want people to really remember it, but gcjx as it is today is
really, really slow. It was more than 10x slower than jikes for
building classpath; now it is merely 6x slower.
>> probably just have to throw out the current parser and write one using
>> a real tool. Most likely, I'll put this off for a while.
Ranjit> People seem to be moving from tool-based to hand-written
Ranjit> recursive-descent parsers (witness the C and C++ front-ends
Ranjit> in mainline). Why do you think the current parser is beyond
Ranjit> redemption?
I'm not totally certain that it is. But it does show up in the
profile a lot more than I think it ought to. That is one problem.
Also it has never had a very good error reporting or recovery
approach, and the idea of throwing exceptions when a parse error is
hit turns out to be pretty bad (e.g., we spend 5 seconds constructing
format_repr objects when parsing an error-free code base). My guess
is that a generated parser would solve both of these problems.
Basically I took a crazy approach to writing a parser and now I'm
having second thoughts :-)
Ranjit> BTW, I applied the attached patch as obvious to restore the
Ranjit> caret-printing feature.
Thanks. And sorry about that.
Tom