Re: speeding up buildworld/kernel

-----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@xxxxxxxxx> 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-----

_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Relevant Pages