Build times for V8

[Erik Corry]

I have a proposal for improving the V8 build times, which I think are
a big issue for many who want to contribute to V8. For example, if I
make a change to a src/objects/objects.h it takes 18 minutes to
recompile V8 on a laptop. This is with gn, ninja, ccache. This is for
building all of V8 including d8, cctest, unittests.

The only solution I know is to compile .cc files in batches (see below
for why this helps). I have some changes to the gni files that add a
compilation flag, v8_enable_cluster_build so that this happens
automatically. It's giving me a 3x improvement on compile times on
both big desktops and smaller laptops.

There are some .cc files that have global name clashes with each
other. I have a set of CLs (linked off the bug at
https://issues.chromium.org/issues/483903200) that fix these name
clashes. For example
https://chromium-review.googlesource.com/c/v8/v8/+/7562658

An alternative approach, which is in
https://chromium-review.googlesource.com/c/v8/v8/+/7585474 is to have
exclusion-lists of such problematic .cc files and just build these
files in the ordinary way. This reduces the source changes to a
minimum. Even with this approach I'm getting close to 3x speedup on
my workstation, but I would personally prefer to fix the .cc files.

I don't envision having a CI bot for the cluster build. Those of us
who benefit from it would maintain it by either updating the
exclude-lists or fixing issues with name clashes in the .cc files. As
such it would not be much of a burden for Google if they choose not to
use it.

With the change we call out to python from the gni files (at gn gen
time). This only happens if the v8_enable_cluster_build flag is
activated, which I don't expect it to be by default. This costs a few
hundred milliseconds at gn gen time, but this is well worth it since
it only affects those using the cluster build option.

Why compiling .cc files together works:

The root of the problem is that there is a large number of .h files
that get pulled into each .cc file. This means, for example, that each
auto-generated .cc file that is made from a .tq file takes 20 seconds
of CPU to compile, even on a fast modern core. This is true even if
the .cc file is less than 100 lines long. (Clang is single-threaded.)

Over the years the number of .cc files has increased dramatically. For
example the regexp engine was a handful of arch-independent .cc files,
plus one or two arch-dependent files. There are now 24
arch-independent .cc files for the regexp engine.

I hear there have been some attempts to improve the situation with .h
files, so that a smaller number of them get pulled into a given .cc
compilation. This is complicated by the fact that some optimization
decisions are based on the compiler seeing a .h (or -inl.h) file that
may not be necessary for correctness. So reducing the number of .h
files in a compilation causes performance regressions that cannot be
entirely fixed with PGO.

I'm still in favour of fixes to the .h files to improve compile times,
but given that people have been trying to do this for some years I
don't think that should be a blocker for a different approach that
actually works now.

Let me know what you think.

--
Erik Corry

[Ben Noordhuis]

Is this a resurrection of the jumbo build? [0] removed that and I, for
one, was very sad to see it go. A data point from an old Node.js issue
I opened:

1. V8, clean normal build, make -j8: 6:30m wall clock time, 47:48m cpu time
2. V8, clean jumbo build, make -j1: 4:37m wall clock time, 4:34m cpu time

It was so much faster in human time and CPU time - staggeringly so in
the case of the latter. Granted, that was 8 year ago!

[0] https://chromium-review.googlesource.com/c/v8/v8/+/1890090
[1] https://github.com/nodejs/node/issues/18742

[Erik Corry]

It's not quite as radical as the jumbo build. As I recall, that tried
to compile everything in one huge compilation. This meant it wasn't
usable for regular development because a .cc file change would take 4
minutes.

In this case we are compiling up to 25 files at a time, and grouping
them by directory. That means a .cc file change is still only about
30s, but the saving in total CPU time is not as dramatic. It also
means you don't get conflicts between completely unrelated files, only
the ones that are in the same directory. The 25-file limit is
configurable in your 'gn gen' or your args.gn - if you have a very
large or small number of cores you may want to adjust. I don't think
github builders have a huge number of cores for example.

Sadly your numbers show how much we have regressed. Neither the
regular build, nor this cluster build are close to those numbers.

I tried to get comparable numbers to your 8 year old test:
* Building just d8 (not the tests)
* -j8
* No ccache
* Current origin/main
* After ninja -t clean
* Xeon (probably much faster than your CPU of 8 years ago)

On Thu, Feb 26, 2026 at 10:03 AM Ben Noordhuis <in...@bnoordhuis.nl> wrote:
> 1. V8, clean normal build, make -j8: 6:30m wall clock time, 47:48m cpu time

Now half that speed on faster CPUS: 13m49s wall clock time, 104:51m cpu time

> 2. V8, clean jumbo build, make -j1: 4:37m wall clock time, 4:34m cpu time

I hadn't tried a j1 cluster build until now, but here it is: Sadly
although the cpu time
is 4x better than non-cluster build, it's 6x slower than the old jumbo build.
Cluster size turned up to max: 24m40s wall clock time, 24m31s cpu time.

For a somewhat more realistic modern developer experience, here's the
-j16 time for the same workload, default cluster size:

$ time ninja -j16 -C out.gn/x64.release d8
ninja: Entering directory `out.gn/x64.release'
[2425/2425] LINK ./d8

real 2m21.231s
user 33m45.009s
sys 1m37.414s

>
> It was so much faster in human time and CPU time - staggeringly so in
> the case of the latter. Granted, that was 8 year ago!
>
> [0] https://chromium-review.googlesource.com/c/v8/v8/+/1890090
> [1] https://github.com/nodejs/node/issues/18742
>

> --
> --
> v8-dev mailing list
> v8-...@googlegroups.com
> http://groups.google.com/group/v8-dev
> ---
> You received this message because you are subscribed to the Google Groups "v8-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAHQurc_2dDruhqJG5RF1peNB9vVv9s5UuUwz9U_kVhnB5W-gtg%40mail.gmail.com.



--
--
Erik Corry, working on V8 at Cloudflare