From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,38d32527e76861de
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-02-15 14:07:03 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!news.telebyte.nl!news-fra1.dfn.de!newsfeed.hanau.net!newsfeed01.sul.t-online.de!newsmm00.sul.t-online.com!t-online.de!news.t-online.com!not-for-mail
From: "Oliver Kellogg" <oliver.kellogg@t-online.de>
Newsgroups: comp.lang.ada
Subject: Re: GPS - A new kind of IDE?
Date: Sat, 15 Feb 2003 23:08:34 +0100
Organization: T-Online
Message-ID: <b2mdin$5gb$04$1@news.t-online.com>
References: <b22hbg$p5l$01$2@news.t-online.com>
 <slrnb49n14.ed.randhol+news@kiuk0152.chembio.ntnu.no>
 <b298nr$9c$06$1@news.t-online.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.t-online.com 1045346711 04 5643 LM-hELYSSBYJ3W 030215 22:05:11
X-Complaints-To: abuse@t-online.com
X-Sender: 520012863826-0001@t-dialin.net
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Xref: archiver1.google.com comp.lang.ada:34135
Date: 2003-02-15T23:08:34+01:00
List-Id: <comp.lang.ada>

I need to correct myself on the data that I posted.

I was just about to switch from ANTLR to GNAT for disappointment
with the ANTLR parser speed when it occurred to me that I had been
compiling the ANTLR C++ runtime and the Ada grammar without -O
(optimize.)

After turning on -O, I've had quite a surprise.

Here are the timing figures (test case: Ada files of polyorb-snap-4566/src)

Without -O for runtime and lexer/parser:
real    2m41.298s
user    2m39.200s
sys     0m0.860s

With -O for runtime and lexer/parser:
real    0m9.895s
user    0m8.250s
sys     0m0.890s

For comparison, "gnatgcc -c -gnats" (which is roughly
comparable in effect to what the above parser does)
performs as follows:
real    0m4.042s
user    0m2.030s
sys     0m2.010s

So in this case the hand crafted parser (GNAT) is still
double as fast as the parser automatically generated
from a grammar (ANTLR.)  Not bad IMHO.


Oliver Kellogg wrote:
> I've just bumped into an interesting data point on
> parser contruction with ANTLR regarding parse speed.
> ANTLR supports syntactic predicates such as
>
>   (subprog_body) => subprog_body
>
> where the rule subprog_body is applied on trial
> and if it turns out not to apply then the parser backs
> out and applies the next rule. Terence Parr, inventor
> of ANTLR, calls this "infinite lookahead".
>
> This feature makes for a prettier grammar because
> it allows more liberal reuse of rules. In the above
> example, we can write the subprog_body rule in a
> place where also a subprog_spec could be expected;
> the parser takes care of resolving the ambiguity.
>
> However, that beauty has its price.
>
> As a test, I submitted the source code of the
> Ada Graphics Package (agp95_v0.1_x11/src) to parsing
> (38560 LOC, 11851 executable semicolons.)
>
> With usage of syntactic predicate for the subprog_spec/subprog_body
> distinction ("pretty" soft-state grammar rule):
>
> real    1m16.635s
> user    1m15.930s
> sys     0m0.300s
>
> Without usage of syntactic predicate for the subprog_spec/subprog_body
> distinction ("ugly" hard-coded state):
>
> real    0m46.058s
> user    0m45.110s
> sys     0m0.370s
>
> So for kdevelop adasupport I'm going with the hard state rule
> for subprograms.
>