Decreasing Chromium's compilation time

ucsdboy

ucsdboy

Hi everyone,

I recently installed FreeBSD onto my Ryzen 1700 w/32GB of RAM and a single SSD. I removed a few options from the kernel and recompiled it and rebuilt world. No issues there It recompiled using -j 14 in a few hours tops. It looks like most of the projects in ports can't use -j option. No worries there most compile quickly enough.

Chromium however... is a dog! It's been going on for two days now and still only 83% done! Anyone know of a way to speed it up? It's a shame the CPU is being vastly underutilized.
 
Replace make -j14 install with make MAKE_JOBS_NUMBER=14 install to have more ports build successfully; defining -j on the command line will have multiple jobs work on the 1 port and when dependencies need to be built they can get multiple jobs building multiple of them but there is no mechanism to make sure they don't have multiple jobs try to work on the same port at once and dependencies of dependencies becomes something that would require sorting. You can also add the definition to /etc/make.conf. Most ports are compatible and the ones that are known to have issues define MAKE_JOBS_UNSAFE in their port's Makefile; < 691 of the over 30,000 ports defined it on my last ports tree download. You should now have most cores utilized. Using a higher # can sometimes help as some jobs will be waiting on things like disk I/O instead of actively using the CPU and the overcommitted jobs will get scheduled which may have CPU work to do in that time.

You can continue to use -j# successfully for world and kernel but if you define PORTS_MODULES in /etc/src.conf then a different can of worms is opened where any ports configuration dialogs will cause the build to hang as the config dialog cannot reach the terminal. Setting up WITH_META_MODE as documented in manpages will further accelerate rebuilding world/kernel when you don't delete the previous build work.

If you end up rebuilding the same version of a port you can install and use devel/ccache or its newer devel/ccache4. Most ports do not benefit when the version of the port changes since they extract the build directory to a version dependent path which by default causes cached results to not be matched on version change. World/kernel will also benefit from this. ZFS+ccache causes a scenario where ccache usually cannot determine newly added filesizes properly (a ZFS bug) which is observed by ccache's reported size being way below the size of the actual cache on disk; try disabling compression, periodically executing a manual ccache cleanup cycle, or use a different filesystem. Disabling atime on the ccache's cache directory makes it unable to track which cache results were recently used but for ZFS users when on magnetic media and a big cache its important to disable to minimize performance killing fragmentation. Alternatively a large cache should be periodically copied (move away+copy back without dedup, block_cloning, etc.) to be kept more organized or performance takes a massive hit; this also speeds up any atime=off cache that has been through multiple cleanups. If stored on a SSD then the ZFS fragmentation impacts will be minimized but still present and writing copies of compiler output is more SSD wear if concerned about that; I'd be more inclined to have atime on for an SSD backed cache so more used results can be kept but haven't performance tested its impacts. Ports that use different compilers (such as previously mentioned Firefox which partially uses rust) are not accelerated by ccache which only helps c/c++ compilers; consider devel/sccache and devel/sccache-overlay to get rust support too though I heard it was a little slower at c/c++.

You can gain performance with different filesystem paramaters but the bigger speed jump will come from replacing it with a tmpfs RAM based filesystem. This will remove its related SSD wear too. If using poudriere to build ports it has options to do that for you but at only 32GB of RAM you will need to define PARALLEL_JOBS=2 or set other restrictions otherwise it will start building up to 16 separate ports at a time which will likely exceed your system RAM with their work directories all being extracted to RAM + the RAM necessary to do the build. Poudriere's config needs ALLOW_MAKE_JOBS=yes to permit running multiple jobs per single port and also reads its own separate /usr/local/etc/make.conf where you can define MAKE_JOBS_NUMBER; not doing so will use the default limit of 1 job per port (and you already know how bad that feels). I've had much better results with a balance of parallel jobs + make jobs both being defined to get an acceptable total job count: max=parallel*make assuming no port bugs like where rust ports have been known to launch multiple compilers per make job; anyone know if thats still a bug?.

If using ZFS, having compression turned on can give you faster disk I/O and store more ZFS data in the same ARC. Turning up compression too high will bottleneck on compression for writes and may bottleneck for reads; the proper setting is only found by trial and error and can be further complicated by if the compiler ran or ccache returned the result with little CPU.

If you have access to multiple machines, you may get some speedup using distcc to offload work to more machines depending on hardware performance.
 
I've had things break by redefining compiler optimizations both up and down but lowering it usually helps get builds moving faster. Making sure to have LTO disabled and removing optional dependencies would similarly speed up the build at the cost of performance and features.
 
Thanks everyone for your replies. It finally finished yesterday and I am now replying from FreeBSD. I will use all your suggestions for the next compile. :)
 
Just a datapoint.
www/chromium consumes 10+ "hours" to build, while
www/firefox consumes 30+ "minutes" to build exact;y on the same PC for me.

Few yeas ago, if I recall correctly, www/firefox consumed 2-3 hours and www/chromium consumed around 1 hour in a short period of months.
This was, if I understand/recall correclty, www/firefox was not as optimum as on nowadays for builds, and www/chromium introduced some aggressive build sequences as trial, maybe precompiled (or merged) headers or something alike. Sadly, even though it made no harm for me, it was reverted back, causing www/chromium to consume 5-6 hours at the time.
Now www/chromium become larger and more complexed, unfortunately.
 
When I googled with keywords "Chromium compile time", it answered on top of page,
On an 80-core machine with -j 72 you should be able to build Chromium in maybe 40 minutes. On a 4 core laptop it probably takes six to seven hours. No CXX task should take 30+ minutes, with the normal clang.
Click to expand...
Maybe found on somewhere in this page.
 
If you regularly build chromium you should definitely get a fast machine. You don't learn anything useful by watching a (possibly failing) build for 2 days.

You don't need 80 cores, 32 do just fine. Seriously, well under a $1000 budget for mainboard, CPU, RAM and cooler you can get chromium under 2 hours. And no laptops unless it is an AMD with 8 real cores. But even then that is lame compared to a proper board.
 
First question is why build from ports?
OK assuming you answer that logically (I need to enable xxx option or I like to disable nasty foo)
Are you building everything from ports? When I was building SeaMonkey I found it much quicker to use packages for dependencies.
cd /usr/ports/www/chromium
make build-depends-list | cut -c 12- | xargs pkg install -A -y
make reinstall
 
cracauer@ said:
If you regularly build chromium you should definitely get a fast machine. You don't learn anything useful by watching a (possibly failing) build for 2 days.

You don't need 80 cores, 32 do just fine. Seriously, well under a $1000 budget for mainboard, CPU, RAM and cooler you can get chromium under 2 hours. And no laptops unless it is an AMD with 8 real cores. But even then that is lame compared to a proper board.
Click to expand...
Just an average machine. Did start the Chromium build this morning and it is all good and done now

Code: 
Installing chromium-127.0.6533.119...
==> Running trigger: desktop-file-utils.ucl
Building cache database of MIME types
==> Running trigger: gtk-update-icon-cache.ucl
Generating GTK icon cache for /usr/local/share/icons/hicolor
===> SECURITY REPORT:
      This port has installed the following files which may act as network
      servers and may therefore pose a remote security risk to the system.
/usr/local/share/chromium/chrome
/usr/local/bin/chromedriver

      If there are vulnerabilities in these programs there may be a security
      risk to the system. FreeBSD makes no guarantee about the security of
      ports included in the Ports Collection. Please type 'make deinstall'
      to deinstall the port if this is a concern.

      For more information, and contact details about the security
      status of this software, see the following webpage:
https://www.chromium.org/Home
===>  Cleaning for chromium-127.0.6533.119
--->  Cleaning out obsolete shared libraries

________________________________________________________
Executed in  384.51 mins    fish           external
   usr time  4242.19 mins    1.45 millis  4242.19 mins
   sys time  137.29 mins    0.31 millis  137.29 mins

But of course, the Firefox just took:
Code: 
________________________________________________________
Executed in   33.52 mins    fish           external
   usr time  335.01 mins  940.00 micros  335.01 mins
   sys time    8.36 mins    0.00 micros    8.36 mins

Firefox build is over 10 times faster. This time includes also downloading the source and unpacking. CPU in this case is an old one - Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
 
Imagine how you would feel with dooble or similar browsers that shoudl compile in few minutes or less...
because the hard/long work is offloaded to the dependencies
 
drhowarddrfine said:
No one would consider a 12-hour build good though many would say they were done and never doing that again.
Click to expand...
It was Executed in 384.51 mins build time. That means 6.4 hours. Of course, sitting behind the computer, this may seem a long time, but one needs not to sit behind the computer when building it.
 
T-Aoki said:
… www/chromium consumes 10+ "hours" to build, while
www/firefox consumes 30+ "minutes" to build exact;y on the same PC for me. …
Click to expand...

1723985750866.png140amd64-quarterly yesterday, build ce3259c6963d
  • 05:19:09 for Firefox
  • 14:12:07 for Electron 30
  • 16:54:56 for Chromium
  • 17:01:50 for Iridium.
 
Mirror176 said:
because the hard/long work is offloaded to the dependencies
Click to expand...
Hah, its true. We could move the chromium port to chromium-core. And then introduce a new chromium port which is basically a shell script that launches the binary from the chromium-core dependency.

The chromium port can be "built" in a couple of seconds ;)

(the problem is that chromium *also* already has a shedload of dependencies!)
 
You must log in or register to reply here.
Back
Top