Chromium compile doesn't seem to be using ccache

[mi_unixbird]

[mi_unixbird]

In case anyone later stumbles upon this thread. I solved the issue, more or less, “ccache -sv” revealed that the error was “compiler check failed” so I removed the “compiler_check” configuration option in distcc.conf. This now does apparently mean that a re-installation of the same compiler version will invalidate the cache but I never had that.
_________________
execctl --path exec filectl --current-directory list

[logrusx]

I spent a lot of time on that back when I had a dual core CPU with maximum limit of 8BG RAM which I didn't even have. Chromium doesn't benefit from ccache either way unless you recompile one and the same version.

Best Regards,
Georgi

[mi_unixbird]

[logrusx]

I haven't compiled chromium for a long time, it still used GCC when I did. Back then it was written in a way ccache wasn't doing much. It used to take around two and a half hours to compile, but with ccache it was taking maybe 15 minutes more when the same version is recompiled and it had very high hit rates.

I then switched to ungoogled-chromium-bin, but ultimately I switched to Firefox.

Best Regards,
Georgi

[mi_unixbird]

[logrusx]

[mi_unixbird]

[Chiitoo]

I believe the last version of Chromium to have USE="jumbo-build" was 78.0.3904.108, which was removed back in 2019 [1].

That flag, when enabled, would usually cut down the build time to half, while using more RAM.

Aside from that, I think Chromium just got bigger.

(Qt still maintains 'jumbo-build' for their fork of Chromium, so one can someawhats test the difference using that still.)

[logrusx]

[mi_unixbird]

Well, we'll see what changes with the next compile, but those three hour build times of Chromium I still had earlier this year before ccache failed do certainly look attractive. We'll see if it go back to that but it's hard to argue with theory against the statistics that in my genlop -t logs of chromium there are 3 hour build times [ccache succeeded], 8 hour build times [ccache didn't succeed due to say a compiler update or the recent problem], and pretty much nothing in between.
_________________
execctl --path exec filectl --current-directory list

[mi_unixbird]

First cached update:

[logrusx]

I still can't believe chromium build makes good use of ccache. There's a new 129 version available. Also 130. I'm curious what will happen with one of those.

Best Regards,
Georgi

[mi_unixbird]

[mi_unixbird]

After getting a similarly abysmal result I did some research and it turns out that depend mode is entirely useless for upgrades because it by necessity needs to use the file pah in the hash then, not simply the content of the file, and since portage includes the version in the file path in the build dir it's of course entirely useless. I read somewhere that depend mode was generally faster but it seemed that only applied to rebuilding the same identical thing twice.
_________________
execctl --path exec filectl --current-directory list

[logrusx]

[mi_unixbird]

[mi_unixbird]

After some further digging and hacking I found that ccache is obviously heavily influenced by line marker metadata emitted by the preprocessor depending on the build system which may include a version number in the path. I now used a compiler wrapper which passes “-P” to the preprocessor to strip this. This led to mesa, a package I didn't use ccache on because hits were abysmal as in the 5% range to actually get over 90% hit ratio now on an upgrade cutting built time down from 9 to 1 minute.

As in: “prefix_command_cpp=/usr/local/libexec/ccache_pp_wrapper” with this simply executing “exec "$@" -P” and nothing more. It seems like this change makes a lot of packages which didn't work well with upgrades compile get a high hit ratio.
_________________
execctl --path exec filectl --current-directory list

[logrusx]

Any news about that?

Best Regards,
Georgi