On Sat, Mar 15, 2003 at 09:37:02AM +0100, ragge@ludd.luth.se wrote:

 > The main "problem" with pcc is that it don't optimize anything, so
 > the resulting code is both large and slow. Pcc-compiled code is about
 > 50% larger than gcc-compiled code.  This is also one of the reasons why
 > it is faster than gcc; it don't do any optimizations on trees.

Right.  Sure, you can have a compiler that runs fast on VAX, but the
resulting code won't run fast on VAX.  Personally, I think a compile-time
penalty is a lot better than a run-time penalty.

Now, I'm not trying to make excuses for the speed of GCC -- it certainly
has gotten slower, esp. in the 3.x-series.  However, there has been a lot
of good work done recently to speed up GCC.  One of the relese criteria
for GCC 3.3 is to fix some of the compile-time regressions.  This work is
also continuing on the mainline (which will become 3.4).  There is also
some hope that 3.5 will be faster yet, since I believe the new tree-based
optimizers[*] are scheduled to be in that release.

[*] Most optmizations are currently done in RTL, one of the side-effects
being a lot of additional RTL being generated during the optimization
passes, which increases the memory/cache footprint of the compiler, esp.
with the new garbage-collecting memory allocator used to support PCH.

Just keep in mind that there are several NetBSD developers who are also
GCC developers, and are aware of the speed issues, and want to solve them :-)

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>