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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:38 EST