Path: utzoo!mnetor!uunet!nuchat!peter From: peter@nuchat.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga Subject: Re: Feeping Creaturism Message-ID: <709@nuchat.UUCP> Date: 29 Feb 88 03:00:27 GMT References: <655@nuchat.UUCP> <657@sandino.quintus.UUCP> <670@nuchat.UUCP> <692@sandino.quintus.UUCP> Organization: Public Access - Houston, Tx Lines: 85 In article <692@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > Hey, I use 'make' too (thanks Fred). But the level of granularity is > wrong. I want to be recompiling PROCEDURES not FILES. ... > the compiler would > then have to read in all the includes FOR EACH PROCEDURE. If I change > 10 procedures, I have to do 10 compiles. Even ignoring the time to load > the compiler (which should be negligible when REZ comes out!), and > even with precompiled includes, this would still be slower than having > all that include information and linkage information already around, so > all we have to do is modify the few things that have changed, and > recompile the 10 procedures. Since you have to have that info around anyway, why not just keep your common precompiled include in RAM:. So all you do is recompile the 4 or 5 files those 10 procedures are in... since the info you'd be caching with your incremental compiler is all in RAM anyway... > Just because > the languages are different doesn't mean that the development styles > have to be. Oh no, the development styles for interactive languages like Lisp, Basic, Forth, and SmallTalk are quite different than for batch languages like Fortran, Pascal, Modula, and 'C'. I've been on both sides of that fence. > Yea, I've been using UNIX for about 3 years, although not exclusively. > That doesn't mean I like it. I find it too big and baroque. So you never worked at understanding how to use it terribly efficiently, nor why certain design decisions were made? > But, according to the Transactor review of Lattice, which compared it > to Manx (3.4, I think), Manx compile times aren't all that much better. > How long does it take you to compile and link, say, a 400 line (not > counting comments) program? I'd really like to know. If it's in the > 30-45 second range, that might be ok. hang on... Compiling in RAM:, with libraries and includes in VD0:, no precompiled includes (for this program thay'd save about 15 seconds)... 150 lines in... 36 seconds. Let me try something bigger... how about browser? info.c 945 rwed Today 20:45:25 pointer.c 873 rwed Today 20:45:24 vollist.c 733 rwed Today 20:45:17 menu.c 7340 rwed Today 20:45:15 browser.c 48862 rwed Today 20:45:07 toolmenu.c 2621 rwed Today 20:44:54 copy.c 5913 rwed Today 20:44:53 As you can see, I don't really practice what I preach about small files. 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. > And after you compile and link your program, and you edit it and change > one variable name somewhere, how long does it take you to compile and > link again. Maximum of 5 minutes for a sizable program. More like a minute if I was being totally cool about modularization, and none of the files were over the 6K of copy.c. If you have an incremental compiler, that goes down to 47 seconds, absolute minimum. > 1. editing > 2. parsing > 3. compiling, optimizing, and assembling > 4. load and linking > 5. debugging 6. documenting. Don't forget that one. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.