Performance compared to lex&yacc?
We might consider using Java for building a C/C++ compiler but are a bit concerned about the performance. Who would be willing to tell
about their experience with JavaCC (and maybe Java in general) when using it for such a relatively large project? And me knowing
lex&yacc, how do you think it compares in term of performance?

Many thanks,
Kees
Reply to this message
 

More info: Get free java help from real people , Free Auto Insurance Quotes - see if you can SAVE!
 
 

Apr 25, 06:40 AM

lubjek@placebase.com (in response to Kees & Annette van der Bent)
Message 2 of 3

Re: Performance compared to lex&yacc?
In article <3904AC17.23D65843@support.nl>,
Kees & Annette van der Bent <vdbent@mail.com> wrote:
Who would
be willing to tell about their experience with JavaCC (and maybe Java in general) when using it for such a relatively large project? And
me knowing lex&yacc, how do you think it compares in term of performance?
Java will naturally be slower than C/C++. The metrics vary a great deal. You have to decide if the performance is "good enough" for your
app.

If you want a fair compairson of JavaCC vs. lex/yacc, you would need to somehow eliminate the Java vs C factor between the two tools.

My personal experience is that for parsing alone, JavaCC is very adequate. I can parse a ~20-50mb file, build an AST, and some other minor
housekeeping in a few minutes of cpu time (on a fast cpu). It is much slower than C & lex/yacc, but is acceptable.

That's the easy part. However, for the real application I'm noticing that I can get the job done easily with Java, but performance is a real
issue. I have to work very hard to write efficient code to keep things from falling apart. But so far, Java & JavaCC are acceptable in my
environment.

Your milage may vary.

--
PlaceBase | Looking for a place to work, stay, or LIVE? the Visual Database of Places | Find it at PlaceBase! No plug-ins required.

http://www.placebase.com | Panoramic (360-degree) views of the Real World.
Reply to this message
 

More info: Get free java help from real people , Free Auto Insurance Quotes - see if you can SAVE!, Free Applications help
from real people, Get free Job advice from real people
 
 

Apr 26, 08:01 AM

Andreas Ludwig (in response to Kees & Annette van der Bent)
Message 3 of 3

Re: Performance compared to lex&yacc?
Kees & Annette van der Bent wrote:
We might consider using Java for building a C/C++ compiler but are a bit concerned about the performance. Who would be willing to
tell about their experience with JavaCC (and maybe Java in general) when using it for such a relatively large project? And me knowing
lex&yacc, how do you think it compares in term of performance?
We are currently doing a similar project, for a Java program transformation toolkit, including a JavaCC parser and some analyses.

In our experience, Java is very productive (little traps, clean code), so this is fine for our research goals.

We also found that
- JavaCC produces the fastest Java parser available
(followed by JavaCUP, afterwards ANTLR).
- Parsing takes about 30-40 percent of the total analysis costs,
while optimization and code synthesis are more critical in a
fully fledged compiler.
- Java is bad in I/O, String handling and memory allocation.
The Problem: A fast compiler requires fast I/O, String handling,
and memory allocation.
To compare two industrial-strength compilers (say, jikes and
javac 2nd edition), you can observer a factor of at least 10
in favor of the C version (jikes is kind of pseudo-C++, that is
C plus some class keywords spread inside).
- Java is almost as fast as C in most other areas.
- Java delivers some things you probably will not need (ability to
parse Unicode, for instance), so comparison is not completely fair.
- With proper optimizations, Java could be compiled to be nearly
as fast as C. Unfortunately, the "dynamic Java hype" is opposed to
this: a global optimization (needed to get rid of String/StringBuffer
indirections) is not feasible in a just-in-time scenario.
- If you compare parsing times, the best known tools will yield C parsers
that outrun the best available Java parsers by a factor of 25 to 100.
Unfortunately, I am not kidding.
- Java memory overhead is kind of an issue, but ASTs grow big regardless of
the language, so this overhead is about 20% due to the garbage collection
and runtime type information.

From the perspective of a software engineer, I would suggest that you check if the benefits of Java (a fast to build and reliable compiler that
is relatively easy to adapt to new requirements) outweight the performance losses.

From the perspective of a user, I would prefer a fast compiler and up to date have not seen a convincingly fast Java compiler yet. I could live
with a factor of two, but watching jikes finishing long before Java has read in the files (physically) is just frustrating.

I hope this was useful.

Andreas Ludwig