NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/compiler/2114

Internet Message Format | 1993-01-07 | 3.6 KB

Path: sparky!uunet!usc!rpi!uwm.edu!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
From: [e-mail] (Paul Robinson)
Newsgroups: comp.compilers
Subject: Compile Time vs. Run Time
Keywords: optimize
Message-ID: <[e-mail]>
Date: 8 Jan 93 02:25:46 GMT
Article-I.D.: comp.93-01-041
Sender: [e-mail]
Reply-To: Paul Robinson <[e-mail]>
Organization: Compilers Central
Lines: 59
Approved: [e-mail]

In a comparison of Compile Time vs. Run Time, you have to take a look at
what is _really_ going on as opposed to what you _think_ is going on.

There are some compilers out there that they "compile" the code almost as
soon as you hit the return key after selecting "Compile" or "Execute" from
a menu or a command.  Even if the code is 1,000 lines, the code is
compiled at "superhuman" speeds.

They cheat.  The code is actually "compiled" as it is typed in, and the
compiler in effect does internal multitasking, in that a line of code is
passed to the compiler for analysis and if it's okay it's compiled either
to tokens or into machine code.  (The editor TECO for the DEC 10 used to
actually _compile_ the teco macros; they ran fast but it took a few
seconds for the macros to be accepted.)

If someone punches a program onto cards and submits it to a mainframe (I
know this usually ended about 5 years ago but bear with me a moment), they
aren't going to care about how long the compile takes, whether it takes 10
minutes or 20 is really irelevant.

On a terminal, a 100% increase in time could be intolerable unless the
user expects it.  On the other hand, if response is _too_ fast, it can
disrupt one's concentration.  RSTS/E had a basic interpreter that scanned
your program as you entered it.  If there was an error in a line, the
*instant* you pressed return, it *BANG*ed back with a message of a syntax
error.  This forced a lot of people to use TECO or some other editor to
write their programs then read them in under Basic Plus.  This caused the
authors of TECO to put in a "BASIC" switch to indicate you were reading a
Basic program rather than other text and it handled it according to the
rules for the interpreter, mainly to put lines without numbers (which were
continuation lines) to NOT be prefixed by a CR.

If I was selling compilers, I'd try and make a "double vision" version;
one that was a dog on the code it created but it compiled *fast* and
another that was slow in compiling but put out excellent code.  Or a
compile time switch to select one or the other.

The reason for doing this is that at an educational installation, the
usual practice is called "compile-link-bomb" as opposed to
"compile-link-go" in commercial organizations.  As a large majority of the
compiles are done for syntax checks and bug eradication, this is what
should be done fast and the code doesn't have to be all that hot since the
user isn't going to use it in 90% of the runs.

This option is even *more* critical in compilers which are used at a PC
and Terminal.  I personally wish Borland would bring back something akin
to their old version 3 of Turbo Pascal.  The compilation speed was
tremendous even on a 4MHZ PC.  And the generated code was surprisingly
good, people who analyzed disassembled code from the program said that it
would be difficult to write the code it generated much better.  I'd like
to see compilers that are much faster in detecting errors and scanning
source, then give you the option to go on and compile for better code
generation.
---
Paul Robinson
[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.