This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc compile-time performance


At 20:18 +0200 2002/05/20, Akim Demaille wrote:
>>>>>> "Paul" == Paul Koning <pkoning@equallogic.com> writes:
>
>Paul> Excerpt of message (sent 20 May 2002) by Hans Aberg:
>>> 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.
>
>Paul> That makes no sense to me at all.  If I could only fix one typo
>Paul> at a time, progress would be quite a bit slower.
>
>I think Hans somewhat distorted Paul Hilfinger's statements.

That may be your opinion, but the quote "..." is exact. Paul Hilfinger's
message in the Bug Bison group Mon May 20 20:21:47 2002, which Akim quoted
in Help Bison as well, noted that in the past (seventies-eighties and
earlier), one sent in a batch of punchcards, and got the compile later,
perhaps even the next day. Under such circumstances, it made sense to type
a lot and send it through the compiler only rarely, hoping on a good error
recovery system.

By contrast, that method is rarely used today, so it is easier to make use
of many compiles on a fast computer and make many compiles.

It also depends on what you want to do: In C++, if a name declaration of
some kind is mistyped, that single typo may generate hundreds of errors.
Sometimes this may happen via some template expansion. This is due to some
lost context or semantic information that the compiler cannot capture.

Under such circumstances, it is better to fix the first error, and then
re-compile; after all, the final C++ code must be without errors in order
to be able to produce the wanted objective code. Also, if a language admits
structured programming, that will reduce on the need for typing.

But in a language like TeX, it might still make sense to have a "panic
mode" as some output that may still be readable to humans is generated. --
I have found though that such a "panic mode" invites poor programming
habits in TeX; rather than trying to fix the problem, people get used to
compiling in panic mode, so that errors never gets fixed.

It seems better to design a language so that it becomes easier to write
correct code.

  Hans Aberg



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]