15:00 But Chromium is not a container or a piece of mined ore. Still, the same approach with "bigger is better" works here as well for the same reasons. We get less overhead.
This graph describes how jumbo's progress on the reference hardware. There are a few things that I want to point out here here.
First, jumbo works, and it has more and more effect as we have added support to more parts of the code. Now blink, content, cc, v8, ui, base and pdfium support jumbo builds. And some pieces I've surely forgotten.
Second, jumbo builds are barely affected by the general slowing down on non-jumbo builds.
Third, we are still far from the full potential of jumbo builds. From testing we know we can get down to 40-45 minutes, and that still leaves enough non-converted that I think we can reach 30 minute full builds on a 4 core machine.
Not included here is all the tests outside blink. They are a substantial part of the compile time but I have no data, and we have also not added any jumbo support to those.
4.8h to 1.6h - 2018-02-14 Opera
Landed: 2174 CPU minutes default, 1614 of those converted to jumbo. Jumbo pieces compile in 180 minutes (9.0x faster). Remaining 560 CPU minutes compile at normal speed. Total: 740 CPU minutes
WIP: 2163 CPU minutes default, 1948 of those converted to jumbo. Jumbo pieces compile in 244 minutes (8.0x faster). Remaining 215 CPU minutes compile at normal speed. Total: 459 CPU minutes
Potential: ~2150 CPU minutes default, 6-9x faster? ~350 CPU minutes (2.5x faster than today)
Less speedup of remaining code because targets are smaller and the fewer files in a target, the less jumbo does.