When I started doing serious coding for the Macintosh at Bell Communications Research, I was originally writing code on a Lisa running MacOS. The compiler we had was Aztec C by Jim Goodnow II. It was slow to load and ran it’s own weak shell, based on a UNIX shell, but without most of the goodies. It was there mostly to run their own version of make or for your to call the compiler and linker on your own.
It ran like treacle in January. As my project grew, I would type in some bug fixes in a point-and click editor, save them, start up the shell, start a build, then take a walk. After coming back, I copied the executable onto a floppy then tried it on a Mac 128, debug and start again. The speed was understandable. The original Mac wasn’t all that fast and the compiler was also based on the tradition UNIX tool chain. It ran the c pre-processor, then the compiler, then the assembler and then finally the linker, which was not particularly well-suited to the monolithic Macintosh environment.
Later, when my Mac was upgraded to a “Fat Mac” and had an outboard ProFile (aka “SlowFile”) hard drive, it had enough oomph for me to develop natively.
A couple years later, I got a copy of Lightspeed C, a new entry in the Mac C compiler market. It was shy on documentation, but it ran like a bat out of hell compared with Aztec C. They were so proud of the performance that during compilation, they put up a dialog box with a line count. It was very impressive.
Later at Adobe, working on Acrobat, we had many thousands of lines to compile on a full rebuild and we had tricks to make that go even faster with Lightspeed C (now Think C). The first trick was a separate high-speed hard drive for the source. The second was a buttload of RAM, a big disk cache and a RAM disk. We put the system headers on the RAM disk and you could tell when the compiler hit system headers because there was no access on the hard drive the line counter went way faster.
Oddly enough, we noted that if the screen saver kicked on during a compile, you could still see the line counter ticking by, which is odd because the point of the screen saver is to prevent exactly this kind of thing from happening.
We found out that the line counter in the compiler had been slowing down the compiler. Let that sink in: drawing numbers to the screen was taking up too much time. What they found was that Apple’s font rendering in Quickdraw was the bottleneck, so they wrote code to hard-write pictures of numbers to video RAM. This is a no-no and would never play nicely with screen savers.
All in the name of speed.