Path: utzoo!attcan!uunet!wuarchive!usc!apple!marc
From: marc@Apple.COM (Mark Dawson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: C++/MacApp questions
Message-ID: <45290@apple.Apple.COM>
Date: 1 Oct 90 16:09:25 GMT
References: <10594@pt.cs.cmu.edu> <242@farcomp.UUCP>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 84

In article <242@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes:
>In article <10594@pt.cs.cmu.edu> mkb@rover.ri.cmu.edu (Mike Blackwell) writes:
>[on using C++ and MacApp under MPW]
>>Is there ANY way to speed things along besides turning on the RAM disk
>>cache? It looks like most of the time is spent in CFront processing all
>>those .h files. Will the dump/load mechanism work here, and if so, can you
>>give me a quick tutorial?

I noticed roughly a 40% speed improvement using the dump/load mechanisim with
the C++/MacApp stuff (compiling our user interface code used to take 16min,
now it takes 9).  Also note that a bigger RAM cache does NOT always speed up
compiling time--if you've made it too big, it will actually slow it down (when
it flushes the cache, it has to write that stuff out to the disk--so a big
cache will have lots of stuff to write out (read:much slower)).  For my work,
(8mb fx, 4mb MPW partion size) I've found that a 96K is the biggest I can use
before performance starts to degrade.

Here is a short "tutorial" on using C++, load & dump, && MacApp
(1) Make a file (I'll call it "MyMacAppDump.h") that includes all of the files
    that your program wants to include:
    // C++ dump header file
    #ifndef _MyMacAppDump_
    #define _MyMacAppDump_
   // system header files that this program uses
   #include <resources.h>
   #include <files.h>
   ...
   // MacApp header files
   #include <UMacApp.h>
   #include <UDialog.h>
   ...
   // your own header files
   #include "myapp1.h"
   #include "myapp2.h"

   #endif
(2) Go into each of your .cp files, erase all #includes for the .h files, and
    replace them with:
    #ifndef _MyMacAppDump_
    #include <mymacappdump.h>
    #endif
    >> if you are using load/dump, _MyMacApDump_ will be defined, so the
       loading in of the headers won't occur (and this will allow it to work
       in the case that you AREN't using load/dump--it won't be defined).
(3) Edit your macapp make file (prg.mamake):
    Add in:  CPlusLoadOptions = -load MyMacAppDump.h.dump
             MyMacAppDump.h.o F (option-f) "myapp1.h" "myapp2.h" ...
    <<I don't add the system or MacApp headers...I assume they won't change>>
             CPlus -mf MyMacAppDump.h -dumpc MyMacAppDump.h.dump 
                   -o MyMacAppDump.h.o {CPlusOptions} {OtherCPlusOptions}
    add to: OtherLinkFiles:   MyMacAppDump.h.o

(4) Now you can build your program: Mabuild -cplusload MyPrg -debug
    note: I've never been able to get -cplusload -debug and -sym to work...
         the linker complains.  Also the .dump file produced can be BIG
         (mine is 1.2mb). 
>
>We are using fx's and IIx's with 50 mHz accelerators and still run out of
>stuff to read.  I think that I'd probably be a lot more productive if we
>were using THINK Pascal and MacApp on a ci instead of C++ on an fx.  There
>is a bright side, though.  I have learned how to juggle during compiles.  
>You can too!
>
Yep, I've gone through my share of books, too.

>>Why oh why can't I compile in the background? I have gobs of real memory,
>>and I'd even spring for another disk for swap space. Sigh. Will Sys7 solve
>>this?
>
>We have no problems compiling in the background with 8 megs (except 
>occasionally the compile or link will fail because it can't get enough memory)

I've had no problems compiling in the background, either (using MPW 3.1 & 3.2).

Mark


-- 
---------------------------------
Mark Dawson                Service Diagnostic Engineering
AppleLink: Dawson.M

Apple says what it says; I say what I say.  We're different
---------------------------------