Path: utzoo!mnetor!uunet!husc6!think!ames!amdahl!nsc!csi!jwhitnel
From: jwhitnel@csi.UUCP (Jerry Whitnell)
Newsgroups: comp.sys.amiga
Subject: Re: Feeping Creaturism
Message-ID: <1443@csib.csi.UUCP>
Date: 10 Mar 88 01:27:01 GMT
References: <655@nuchat.UUCP> <657@sandino.quintus.UUCP> <670@nuchat.UUCP> <709@nuchat.UUCP> <714@sandino.quintus.UUCP>
Reply-To: jwhitnel@csib.UUCP (Jerry Whitnell)
Organization: Communications Solutions Inc., San Jose, Ca
Lines: 74

In article <714@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
|In article <709@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes:
|> Let's time a full RAM: compile, eh?
|> 
|> 20:47:00 at start. Doing a bit of blitting around...
|> 20:49:46 when browser.c has finished compiling. 2:46 for ~50K of code.
|> 20:51:00 when all the rest have compiled. Another 1:14.
|> 20:51:47 and it's all linked. Total of 4 minutes and 47 seconds. I guess
|> I could take at most about a minute off for precompiled includes. I keep
|> promising myself I'll chop browser.c up one of these days. Judge for yourself
|> if this is fast enough.
|
|A bit slow, but not too bad IF I DON'T HAVE TO DO IT VERY OFTEN.

Actually, very slow.    ~60K bytes of source is ~3000 lines (plus includes)
on my Mac plus would take < 30 seconds.  From hard disk.   Even less on
my Mac II (with 1/2 mb of cache :-).

|
|
|Why?  I still claim that a small change that only affects two or three
|procedures needn't take more than a few seconds to recompile and
|relink.  Remember, I'm talking about an INCREMENTAL compiler and
|INCREMENTAL linker.  They would only parse the few procedures that have
|changed (which, let's assume, are on ram disk of some sort), and
|compile them.

The compiler I'm talking about above is LightspeedC.  It is not an incrmental
compiler, but a full file compiler.  Similar compilers exist on the IBM PC
(TurboC and QuickC).  The technology for writting simple fast compilers
exists, why write complicated compilers?

|  An integrated environment (let me hasten to repeat:  I'm
|not endorsing the idea of integrated environments, just pointing out
|again that they have some advantages) would not have to produce an
|executable until you ask for one.  It could compile right into memory,
|back-patch, free up the memory consumed by the old version of changed
|procedures, and fire up the debugger.  That would be FAST, much faster
|than 47 seconds.  Where'd the 47 number come from, anyway?

On the order of 30 seconds for a full recompile, less then 10 for changing
a single file (on a Mac Plus, somewhat faster on a Mac II).  With a
multitasking operating system such as MultiFinder or the Amiga OS, one
can run the program under test as a seperate process and when it completes
(assuming the machine is in a usable state), switch back to the
integrated enviroment.  One can switch at any time to look at source
code or make changes.  Not theory, fact on the Macintosh.  If you
havn't seen it, find some Mac hacker with LightspeedC (preferably one
with enough memory to run MultiFinder and a fast hard disk).  It will
make you jealous of the Mac for the first time :-).  Believe me, compared
to 5 minute compiles, it's the only way to program.
|
|It's not the language that makes development slow.  We CAN have speed,
|and portability, and still have a decent development and
|experimentation environment.  When the program is tested, THEN you
|produce the stand-alone takes-5-minutes-to-compile-and-link version.
|This should be possible.  At least in principle.

Oh it is possible, and practicle and doable.  See LightspeedC as an
example.

|
|I hope JimG and JohnT are listening :-).
|-- 
|-Peter Schachte
|pds@quintus.uucp
|...!sun!quintus!pds


Jerry Whitnell				Been through Hell?
Communication Solutions, Inc.		What did you bring back for me?
						- A. Brilliant

g/^>/s//|/     Take that, inews!  Too many lines, indeed.