Related articles |
---|
[5 earlier articles] |
Re: parsing tools, was Dragon Book - update necessary? iank@idiom.com (2000-11-01) |
Re: parsing tools, was Dragon Book - update necessary? jmochel@foliage.com (2000-11-01) |
Re: parsing tools, was Dragon Book - update necessary? joachim_d@gmx.de (Joachim Durchholz) (2000-11-01) |
Re: parsing tools, was Dragon Book - update necessary? LLkParsing@aol.com (2000-11-01) |
Re: parsing tools, was Dragon Book - update necessary? rhyde@cs.ucr.edu (Randall Hyde) (2000-11-04) |
Re: parsing tools, was Dragon Book - update necessary? rhyde@cs.ucr.edu (Randall Hyde) (2000-11-04) |
Re: parsing tools, was Dragon Book - update necessary? LLkParsing@aol.com (2000-11-05) |
From: | LLkParsing@aol.com |
Newsgroups: | comp.compilers |
Date: | 5 Nov 2000 20:49:10 -0500 |
Organization: | Deja.com - Before you buy. |
References: | 00-10-061 00-10-221 00-11-014 00-11-030 |
Keywords: | interpreter, performance |
> > - Interpreted languages like Java do not scale unless they can be
> > compiled.
>
> Not sure what you mean here. Could you elaborate? Interpreted code
> typically runs some constant factor slower than compiled code. An
> algorithm should "scale" at the same rate whether it is interpreted or
> not.
I should have left off the "unless" part. What I really mean is that
an interpreted language can bog down on large inputs. My example is
not Java, but IBM's REXX language, which is interpreted. We had a
program that worked fine on small inputs. However, run times increased
to well over six hours as the size of the input grew. The YACC rewrite
ran in less than a minute.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.