Chromium build time...

[The_Great_Sephiroth]

OK, I build Firefox, Thunderbird, and LibreOffice from source. FF/TB each take about two hours. LO takes about four hours. So why the heck does Chromium take TWELVE hours? Is it really that bloated? Is there some kind of functionality that FF does not have that requires so much more code? I am merely curious because I did not have "USER_NS" set and now I get to rebuild it, if I can find the time to do it.

Code: Select all

~ $ sudo qlop -tH www-client/firefox
firefox: 1 hour, 11 minutes, 19 seconds for 24 merges
~ $ sudo qlop -tH mail-client/thunderbird
thunderbird: 1 hour, 47 minutes, 55 seconds for 19 merges
~ $ sudo qlop -tH app-office/libreoffice
libreoffice: 6 hours, 59 minutes, 59 seconds for 16 merges
~ $ sudo qlop -tH www-client/chromium
chromium: 11 hours, 59 minutes, 2 seconds for 1 merges

OK, so LO is up to almost seven hours. Still, why so long for Chromium? I am running on 64bit using a Core2Duo (P8600) with four gigs of RAM.

[eccerr0r]

Webkit-gtk also takes forever... how long does it take if you have it?

Chromium has its own copy of webkit internally I think "blink" ...

I opted against using chromium... and use epiphany if I have to use webkit, since Evolution needs webkit...

[Ant P.]

Is it really that bloated? Is there some kind of functionality that FF does not have that requires so much more code?

Yes and yes.There's very little difference between Chromium and ChromeOS, and you're building several heavyweight parts: Skia for the GUI, the V8 compiler, that NaCl plugin API nobody uses, an XMPP implementation (for sync), the KHTML/WebKit/Blink engine (which was bloated 15 years ago and only got worse), and so on.
It pulls in *as many* dependencies as Firefox does, but doesn't *make use* of them nearly as much.

[NathanZachary]

... and apparently in >=www-client/chromium-58, there's now a requirement for net-libs/nodejs. I still can't workaround the "bindist" USE flag problem with OpenSSL (needs to be unset for NodeJS, but set for OpenSSH).

Found that the only fix in my case was to globally unset bindist:
viewtopic-t-1051288-highlight-.html

[The_Great_Sephiroth]

Wow, thanks for the info! I have been using it today and speed-wise, on my 300Mbps connection, I see zero difference between it and Firefox. I even run AdBlock Plus in both. Only real difference I see is that Chromium phones my activities home to Google. Firefox does not. I'll use it for a bit and decide whether or not I want to keep it. The long build time is a HUGE turn-off. However, I have read that the sandboxing in Chromium, under linux, is far better than in Firefox.

[Juippisi]

Only real difference I see is that Chromium phones my activities home to Google. Firefox does not.

You could use ungoogled-chromium from pg_overlay. The patches follow stable channel, so it gets updated ~once a week. I agree the build-times are a huge turnoff, luckily for me it takes a bit over an hour, but Firefox is less than 15 minutes so theres a HUGE difference.

But yeah, the privacy is the reason I want chromium instead of the binary google-chrome...

[Goverp]

IIRC someone said compiler caching (ccache) helps improve rebuild time for Chromium. I guess it could be selectively enabled using package.env entries. I've not tried it, and a brief Googling of "chromium ccache site:forums.gentoo.org" makes it look an interesting experiment.

I gave up Chromium 'cos of the compile times a couple of years back, but Firefox's desire to install PulseCrap on my machine will get me to review this decision.

[Juippisi]

IIRC someone said compiler caching (ccache) helps improve rebuild time for Chromium.

Yes, that has been discussed many times, and the summary is that chromium code changes so much in each release that ccache doesnt help much, and it even causes more problems than gives advantage. (like segfaults?)

[Ant P.]

However, I have read that the sandboxing in Chromium, under linux, is far better than in Firefox.

Firefox can use the same sandbox, but it isn't compiled in by default (and the ebuild doesn't help).

[The_Great_Sephiroth]

Thanks, Ant! I may look into that. Also, I have not noticed PulseAudio on my system. Not sure how you're getting it. I am on my gaming rig right now so I am in Windows, but I will look again the next time I use my laptop. I sue the system libraries when compiling Firefox and Chrome, and I do not believe I have pulled PulseAudio down. Thanks for all the feedback. Good to know that even on modern processors Chromium takes eons compared to the other browsers.

[vovan47]

Hi guys! Is it normal that chromium build takes 13,5 hours on my not so old machine?..

Code: Select all

# genlop -t chromium
 * www-client/chromium

     Mon Nov 19 06:08:41 2018 >>> www-client/chromium-70.0.3538.67
       merge time: 13 hours, 28 minutes and 21 seconds.

My specs:

Code: Select all

GPU: AMD ATI Radeon R7 370 
CPU: AMD A8-6500 APU (4)
16 GB RAM
SSD
Kernel: 4.14.78-gentoo 

make.conf:

Code: Select all

COMMON_FLAGS="-O2 -march=bdver2 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"
MAKEOPTS="-j4"

VIDEO_CARDS="amdgpu radeonsi"
USE="X icu alsa lm_sensors apache2 cgi fpm pulseaudio"

[Olis]

IIRC someone said compiler caching (ccache) helps improve rebuild time for Chromium.

Yes, that has been discussed many times, and the summary is that chromium code changes so much in each release that ccache doesnt help much, and it even causes more problems than gives advantage. (like segfaults?)

I disagree. I'm using ccache all the time and I never had segfaults with chromium, neither during compilation, nor during runtime. For me, it saves a lot of time. I'm using an old Intel Core I7 (Sandybridge CPU, 6 years old) with 14 GB RAM and 8 GB swap. Ccache is 5 GB in size and located on a SATA SSD. Usually compiling a minor version update takes less than an hour, major upgrades (eg from v70 to v71) take longer.

In the past I also used MAKEOPTS="j7", but with Chromium 71.0.3578.80 I had to reduce it to "-j2". Although I disabled "jumbo-build" compiling v71 with "-j7" ate up all my memory. Even reducing to "-j4" didn't help. I'm now compiling Chromium with

Code: Select all

MAKEOPTS="-j2" emerge -aquv1 www-client/chromium

which works.

[vovan47]

Wow, this time it actually took 9,5 hours

Code: Select all

     Sun Dec  9 21:08:21 2018 >>> www-client/chromium-70.0.3538.110
       merge time: 9 hours, 32 minutes and 7 seconds.

[Juippisi]

IIRC someone said compiler caching (ccache) helps improve rebuild time for Chromium.

Yes, that has been discussed many times, and the summary is that chromium code changes so much in each release that ccache doesnt help much, and it even causes more problems than gives advantage. (like segfaults?)

I disagree. I'm using ccache all the time and I never had segfaults with chromium,

Yeah, that post was from 2 years ago. It looks like nowadays the rate of chromium releases is faster so not that much of code has changed between releases. Also looks like many people successfully use ccache, so now I would recommend it too.

[vovan47]

Wow, this time it actually took 9,5 hours

Code: Select all

     Sun Dec  9 21:08:21 2018 >>> www-client/chromium-70.0.3538.110
       merge time: 9 hours, 32 minutes and 7 seconds.

Another emerge of version 71 just a week after:

Code: Select all

     Mon Dec 17 13:27:22 2018 >>> www-client/chromium-71.0.3578.80
       merge time: 9 hours, 20 minutes and 53 seconds.

Just out of interest, I've emerged the same version again with USE="jumbo-build" and EXTRA_GN="jumbo_file_merge_limit=25".
It's exactly 3 times faster:

Code: Select all

     Wed Jan  2 20:06:27 2019 >>> www-client/chromium-71.0.3578.80
       merge time: 3 hours, 22 minutes and 51 seconds.

And I've also installed CCache, it grew uo to 933.3 MB after compilation. I hope for even better result next time