[antlr-interest] Re: Local lookahead depth

lgcraymer lgc at mail1.jpl.nasa.gov
Fri Nov 14 11:55:30 PST 2003


--- In antlr-interest at yahoogroups.com, "Anthony W Youngman" <Anthony.Youngman at E...> wrote:
> I agree with Oliver !!!
> 
> Have you EVER hit this sort of problem in real life? I reduced an
> estimated run time of about a week, to an actual run time of under an
> hour, by eliminating disk access from a program. (The estimate was
> achieved by extrapolating from partial runs.)

Certainly.  This isn't rocket science, although you'd think that disk use optimization was a black art from this discussion.  The 
example Oliver used is fundamentally serial--disk thrashing is not an issue unless you buffer data very poorly.  Even when you have to 
do LRU buffering in application software (as opposed to being able to use mmap() or the equivalent for hardware/OS support), you 
should get excellent performance.  The problem is that most developers learn to think of disks as stream devices and not block 
devices and structure their code to have abysmal I/O as a consequence.

> And as Oliver may remember :-) I was in a spat on the relational theory
> newsgroup (which has died down now) about how Pick will smoke SQL for
> speed. While performance may be similar while all the data is cached in
> RAM, as soon as there is any hint of disk thrashing SQL will be hammered
> while Pick is hardly affected - because you can prove mathematically
> that Pick disk i/o is almost optimally perfect :-) Would YOU try running
> a 32-user interactive db on a 386 with 16Mb ram? We did the equivalent,
> and it was plenty fast (actually, it was a MIPS R3000).

The example I'm more familiar with is a system that Forth, Inc. did for a Canadian telecom company back in the '70s.  They supported 
256 users on a 64K VAX with very acceptable interactive performance, some of which is from the lightweight cooperative 
multithreading, and the rest to the disk buffering.

--Loring

> Cheers,
> Wol
> 
> -----Original Message-----
> From: Oliver Zeigermann [mailto:oliver at z...] 
> Sent: 10 November 2003 07:23
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Re: Local lookahead depth
> 
> > > 
> > > I have the same experience. But consider extremely large amounts 
> > of 
> > > input to be parsed. In this case it is prohibitve to generate an 
> > AST 
> > > because of the memory issue. As a very practical exmaple I have 
> > parsing 
> > > of the AMM (Aircraft Maintenance Manual) which is available in 
> > SGML 
> > > (very hard to parse, really). I parsed this a few years using 
> > ANTLR, but 
> > > its size normally is around 100MB. A few years ago my machine had 
> > 128MB 
> > > of RAM! You see what I mean?
> > 
> > And how much disk space did you have?  On a UNIX box, mmap() is a 
> > good way of automating file I/O, but even on systems without virtual 
> > memory, you can fake it. Performance is not an issue--with a problem 
> > of this size, nothing stays in the processor cache, and the overhead 
> > of the disk writes will be only a few percent.
> > 
> > --Loring
> 
> 
> Loring,
> 
> are you really serious about this? Have a look at the DOM vs. SAX
> discussion in the XML area...
> 
> Oliver
> 
> 
>  
> 
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/ 
> 
> 
> 
> 
> 
> ***********************************************************************************
> 
> This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to 
you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to 
anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the 
e-mail from your information system.
> 
> Telephone numbers for ECA International offices are: Sydney +61 (0)2 9911 7799, Hong Kong + 852 2121 2388, London +44 (0)20 
7351 5000 and New York +1 212 582 2333.
> 
> ***********************************************************************************


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




More information about the antlr-interest mailing list