On 06/09/21 10:08, Jeremie Le Hen wrote:
Hey,
I want to build -CURRENT again from sources. It's been a long time
since I hadn't done that. I'm shocked by the compilation time.
I started the whole thing on Friday night and Monday morning it's
still in stage 4.2 (building libraries). Through occasional glancing
at the screen over the weekend, it seems obvious to me that the
compilation time is utterly dominated by LLVM. Compiling C++ seems
extremely CPU heavy and this is made worse by the fact LLVM is built
twice (once for build/cross tools, once for the actual world).
So OK, my CPU is not the most powerful out there but it's still decent [1].
So I have a couple of questions coming to my mind:
1. Is there any optimization I could benefit from? (I'm sure there's a
knob to use the existing compiler instead of building a
cross-compiler.)
I'm routinely compiling head once a month or so on an "i7-6700 CPU @
3.40GHz" (from dmesg), slightly more powerful than an i5 but this is a
relatively old one so not top notch anymore. It usually takes less than
4 hours. I also build a NanoBSD image from scratch from time to time to
an even older i5, which takes a little longer, but always under 6 hours,
so the build times you report look anomalous.
So as already suggested make sure yiu are using parallel make jobs (-j
option to make) and memory is large enough (I think you need at least 2
GiB for make job is the minimum to not risk thrashing.
You should really enable meta mode (look for WITH_META_MODE in
src.conf(5)). It will not help the first time but will help a lot in
future recompilations with an already populated /usr/obj.
You could also investigate using ccache, which again will only help for
successive rebuilds, and will consume a fair amount of disk space.
Another consideration, my builds are happening on SSD disks, with swap
on SSD, if you have everything on spinning media that is also a slowing
factor. If you have plenty of ram you could build in ram, which is what
I'm doing with poudriere for ports and it really speeds things up (even
SSD disks tend to get slower when hit with a constant high load of mixed
read/write accesses, which poudriere with parallel builds sometime causes)
Hope this helps!
--
Guido Falsi <m...@madpilot.net>
