New issue
Advanced search Search tips

Issue 627528 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

Possible speedup by eagerly starting long compilation units in ninja

Project Member Reported by primiano@chromium.org, Jul 12 2016

Issue description

Forking from internal bug b/30007023, idea for possibly making build faster. Filing a bug so we don't keep track of this, might be a nice 20% proj.

By looking at some ninja log traces from the bots (e.g., [1,2]) looks like the last ~minute of the C++ build phase (i.e. the pre-linking edges) are not that parallel. The reason seems to be the following by eye-balling the traces:
some, fortunately few, compilation units take a huge amount of time (minutes instead of seconds). when they are scheduled too late in a -j pool, all the other compilation tasks are done and the only thing ninja can do is sit there waiting for the long tasks to be run.
If we knew in advance (here's the tricky part) the duration of a task, ninja could do some fancier Least slack time scheduling. Or more simply just scheduling those jobs first could be a good enough approximation.


The idea here is that we could have a list of known long compilation units checked in the repo and feed that into ninja to bias its scheduling decisions. Might be worth a try, by eyeballing the traces looks like it could save approx 1min of build time.

Here's a graphic explanation of what I'm saying (I am in the ascii art mood today)

Current schedule
 1  +---------------------+
    |T1|T2|T3|     T4     |
    +---------------------+
                          |
 2  +----------------+    |
    |T5|T6|T7|   T8  |    |
    +----------------+    |
                          |
 3  +--+                  |
    |T9|                  |
    +--+                  |
                          |

Possibly smarter schedule
1  +---------------+      |
   |     T4     |T1|      |
   +---------------+      |
                   |      |
2  +-------------+ |      |
   |   T8  |T5|T6| |      |
   +-------------+ |      |
                   |      |
3  +-----------+   |      |
   |T9|T2|T3|T7|   |      |
   +-----------+   +      +

Here's the win:    <------>

(This assumes that all T1-T9 tasks are not dependent onto each other, which should be sufficiently true for most of our compilation tasks)

[1] https://chromium-build-stats.appspot.com/ninja_log/2016/07/12/build11-m1/ninja_log.build11-m1.chrome-bot.20160712-035857.4228.gz/trace.html
[2] http://chromium-build-stats.appspot.com/ninja_log/2016/07/12/slave136-c1/ninja_log.slave136-c1.chrome-bot.20160712-044917.12688.gz/trace.html
 

Comment 1 by thakis@chromium.org, Jul 12 2016

This is a bit of a faq. The short summary is that I have a branch on my github somewhere that gives ninja a critical path scheduler, but in practice that makes things way slower, presumably because it's very bad for the disk cache. https://github.com/ninja-build/ninja/issues/376#issuecomment-72970593 is a short summary (but that issue has grown several generic "my build is slow too" type comments)

Sign in to add a comment