Re: GCC speed (was [PATCH] Isapnp warning)

[Daniel Phillips <phillips@arcor.de>]

On Sunday 22 June 2003 19:32, Andrew Morton wrote:
> Daniel Phillips <phillips@arcor.de> wrote:
> > As for compilation speed, yes, that sucks.  I doubt there's any rational
> >  reason for it, but I also agree with the idea that correctness and
> > binary code performance should come first, then the compilation speed
> > issue should be addressed.
>
> No.  Compilation inefficiency directly harms programmer efficiency and the
> quality and volume of code the programmer produces.  These are surely the
> most important things by which a toolchain's usefulness should be judged.
>
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.

True, and then gdb works much better as well.  I was really thinking about 
production quality.  Well, I want to have it all, I wonder if the gcc crew 
could come up with a compile speed optimization switch, which produces sucky 
code but does it in record time.

There are many other ways of improving kernel build speed of course.  One of 
the best was to use Keith Owen's kbuild 2.5, which did an impressive job of 
speeding the build up, especially the incremental stuff that matters most to 
developers.  But alas, it died on the horns of politics.

> Compilation inefficiency is the most serious thing wrong with gcc.

If that's the case then it's a good sign I think.

Regards,

Daniel