Find the optimal jumbo chunk size |
|
Issue descriptionIt's possible to configure the maximum size of a jumbo chunk so that you never compile more than X source files in one translation units. The larger X the more efficient use of clock cycles, but the less parallelism and the larger single-file recompilation cycles. The optimal value depends on hardware. Fewer cores should use a higher value for X. More cores should use a smaller value. If the number of cores is infinite, the optimal value of X is probably close to 1. Bruce Dawson has done measurements on 24 core Windows with clang and VC2017 and with goma and not goma. I have measured on a basic 4 core machine. Arguments can be made for values all between 10 and 50 (and even 100 for bot-like workloads).
,
Oct 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/266d520cf6192450fcdca6c06634ad9524cae06a commit 266d520cf6192450fcdca6c06634ad9524cae06a Author: Daniel Bratell <bratell@opera.com> Date: Sat Oct 21 11:31:23 2017 Reducing default jumbo chunk size from 100 to 50. Bruce Dawson and I have mesaured what compile times you can expect from different chunk sizes and it seems that the advantages of 100 over 50 is at best small so this patch reduces the default to 50. It will mean that 100 becomes less likely to work without code fixing since fewer people will compile with 100, but it should be an overall better experience because smaller jumbo units means single-file changes need to recompile less unchanged source. Bug: 766294 Change-Id: I5347c39ad91fbdcd83ea975884ccdb60aa8bbe45 Reviewed-on: https://chromium-review.googlesource.com/671783 Commit-Queue: Daniel Bratell <bratell@opera.com> Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> Cr-Commit-Position: refs/heads/master@{#510679} [modify] https://crrev.com/266d520cf6192450fcdca6c06634ad9524cae06a/build/config/jumbo.gni
,
Oct 21 2017
So now it's 50. I wonder if the best way would to have some bots use <infinity> and then make it dynamic based on some criteria. The main problem has been to support different numbers but <infinity> would hopefully catch all possible problems. |
|
►
Sign in to add a comment |
|
Comment 1 by brat...@opera.com
, Sep 18 2017