>>>>> "Julian" == Julian Bean <jules@mailbox.co.uk> writes:

Julian> I have always found gcc to be rather slow on my NetBSD
Julian> machine, and a recent example really brought it home.

Julian> I was compiling ImageMagick on my LCIII running port-mac68k.
Julian> That's a 25Mhz 68030 with FPU, and 12M of RAM.

Julian> I am fairly sure that Think C 5.0 for the Macintosh compiled
Julian> at 60K lines/minute on a IIci.  And a IIci is also a 25Mhz
Julian> 68030 with an FPU.  Now that wasn't optimized, and this is gcc
Julian> -O2, but I still don't think that makes up for it.

	Well, first off the mark, -O2 will take as much as 75% of the
compile time to run.  In my experience this is exsaserbated by large
functions in large files (which is further exsaserbated by the amount
of memory that it can consume).

	Secondly, gcc is definately not a fast compiler.  If you
wanted to design a really fast compiler, you'd make your
'intermediate' language tightly coupled to your CPU's machine
language, if not a sub/superset of it.  Gcc uses a very generic
intermediate language (to facilitate a number of different 'back
ends').

	I have noticed that the 'stock' compilers on most machines
compile 'faster' than gcc.  This is espeically true on the Hp that we
have at work.  However, if your job at Hp is to make the compiler
fast, there's a lot of assumptions that you can make that we (and the
authors of gcc) cannot.

Dave.

-- 
----------------------------------------------------------------------------
|David Gilbert, PCI, Richmond Hill, Ontario.  | Two things can only be     |
|Mail:      dgilbert@jaywon.pci.on.ca         |  equal if and only if they |
|http://www.pci.on.ca/~dgilbert               |   are precisely opposite.  |
---------------------------------------------------------GLO----------------