Re: gcc compile-time performance

[Paul Hilfinger <hilfingr at EECS dot Berkeley dot EDU>]

> >>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:
> 
> >> As noted by Paul Hilfinger in the Bug Bison list, widespread access
> >> to interactive computing makes it more prudent with a "compile to
> >> the first syntax error, fix, and repeat" approach.
> 
> Robert> I know that theory, but in practice we find that in the GNAT
> Robert> world, where error messages are good, and the compiler very
> Robert> rarely gets derailed, people want to see as much as posisble
> Robert> in a single run.

My words were "increasingly viable", as opposed to "preferable."  In
the old days, it would have been unthinkable to stop at the first
error, since that would have meant at least tens of minutes per minor
syntax error.  Now it often means tens of seconds or less (on my home
computer, GNAT can do plain syntax analysis so fast that the "gcc ..." lines
output for each file by make (well, gnatmake) scroll almost as fast as
I can read them). So now, getting one message per compilation is no
longer disasterous (which is not to say it is DESIRABLE, just not
fatal).

My larger point was that with just a little, rather unintelligent,
error recovery (such as what Bison provides) you get a large number of
useful messages before having to recompile, and recompilation loses
less than a minute.  Therefore, putting a lot of effort into
increasing the number of useful error messages per compilation is not
likely to have a large payoff in throughput.

GNAT's real advantage, in fact, is not so much in good error RECOVERY,
as in good error DIAGNOSIS: its messages are MUCH better than the
usual GCC standard.  Panic-mode error recovery is never going to give
you that.

Paul Hilfinger