This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gcjx] Patch: FYI: parser and lexer changes


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]