speeding up buildworld/kernel

[Aryeh M. Friedman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Trulsson wrote:
> On Thu, Jan 24, 2008 at 03:32:18PM -0500, Maxim Khitrov wrote:
>> On Jan 24, 2008 3:15 PM, Aryeh M. Friedman
>> <aryeh.friedman at gmail.com> wrote:
>>> I update my sources at least once a day and do
>>> buildworld/kernel just as often... It seems some stuff that
>>> needs not be recompiled is on every single run for example gcc
>>> and kerbos.   I have NO_CLEAN in /etc/make.conf is there
>>> anything else I can do to speed stuff up... for ref here is my
>>> /etc/make.conf:
>>>
>>> CPUTYPE?=nocona KERNCONF=MONSTER NO_CLEAN= NO_LPR= # added by
>>> use.perl 2008-01-17 11:48:48 PERL_VER=5.8.8 PERL_VERSION=5.8.8
>>>
>>> - -- Aryeh M. Friedman FloSoft Systems, Java Tool Developers
>>> Developer, not business, friendly
>>> http://www.flosoft-systems.com
>> I might be wrong, but NO_CLEAN seems like a bad idea except in
>> special circumstances. Install ccache, but make sure you set
>> CCACHE_HASH_COMPILER environment variable to 1. That will make
>> sure that the cache stays valid if the compiler executable is
>> overwritten by an identical copy (as it would be on
>> installworld). When the compiler changes the cache will be
>> repopulated on the next rebuild.
>
> You are indeed wrong.  NO_CLEAN will work fine almost all the time
> - except in special circumstances.  The few times it does not work
> one can always do a 'make clean' by hand first. (Or even faster:
> 'rm -fr /usr/obj/*') If you set WRKDIRPREFIX to some useful value
> you can do the same thing for the ports tree. Personally I always
> compile with -DNO_CLEAN and use 'rm -fr' to clean. I have never had
> problems originating with this.
>
> ccache is not very useful for buildworld, since among the first
> thing buildworld does is to build the compiler and then use the
> newly built compiler to compile the rest. I.e. the already
> installed compiler (which is the one ccache will handle) will not
> be used for most of the build thus removing almost all the
> advantage of ccache. It is supposed to be possible to use ccache
> for buildworld as well, but that would require a bit of hackery.
>
>
> As for speeding up the build even more there a couple of things
> that can be tried:
>
> You can add NO_PROFILE=true to make.conf if you do not need
> profiling libraries.

I thought most profiled libs had been removed in current but I will
try this.  I was also looking at NO_SHARED but my gut says this would
cause a sigficant performence hit.
>
> Set CFLAGS/COPTFLAGS to -O instead of -O2. This should speed up the
>  compiler a bit since it will no have to do as much work.  This
> will make programs slightly less well optimized, but since the vast
> majority of the system binaries are not really CPU-bound anyway it
> is unlikely that any performance loss will be noticed.

Do you have any numbers on this?
>
> If you have more than one CPU-core in your machine (and an
> SMP-enabled kernel) you can use the -j flag to tell make to run
> several jobs in parallell.  Just be aware that building with -j
> does get broken occasionaly and there is no promise that it will
> always be fixed quickly. If you do run into problems when building
> with -j, try without -j before sending any bug reports.

Since I like to run it in the background (i.e. while doing stuff on a
different X screen) I usually don't use -j unless I am doing a bare
metal install and then I typically do core*4+2 for it's value.
>
>
>
>
>


- --
Aryeh M. Friedman
FloSoft Systems, Java Tool Developers
Developer, not business, friendly
http://www.flosoft-systems.com

    "Free software != Free beer"

Blog:
 
http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmP9KQi2hk2LEXBARAu7zAJ4/sGAzpMFCZOKkZBVx/s07KTRw9gCgwF1m
6ee/hiJIvj8gyieoq/ZxIz0=
=tnVh
-----END PGP SIGNATURE-----