On Wed, Aug 29, 2018 at 11:36 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 8/29/18 10:32 AM, Ted Mielczarek wrote: > >> so it's possible that there are things here that are artifacts of our tup >> build implementation. >> > > Worth keeping in mind, thank you. Would that possibly account for the > exactly-the-same 99:44 rebuild times for a number of files? > > Reading through this list again, I'm a little suspicious that > testing/webdriver/src/lib.rs has the same rebuild time as > servo/components/style/values/specified/mod.rs, for example... > In this case, the 99:44 rebuild times look to be an artifact of how the outputs of GenerateServoStyleConsts.py are consumed by a large chunk of the Rust and C++ code. Attached is a graphviz .dot file for reference (with graphviz, 'dot -Tpng servo-style-consts.dot > servo-style-consts.png' and view the image). At the bottom of the image are testing/webdriver/src/lib.rs and servo/components/style/values/specified/mod.rs. The rebuild time is calculated by following the links up the graph and adding up the runtimes of the commands (shown as rectangles). Even though the mod.rs file is directly consumed by compiling the style crate, lib.rs ends up with the same subgraph of the DAG, so it has the same total runtime. Since GenerateServoStyleConsts.py has a lot of input files, you'll likely see the same runtime for all of them. In practice for incremental builds, changing lib.rs will likely have a lot faster build time than changing mod.rs. When cargo looks at lib.rs, it only checks that it exists and ignores its contents. So modifying that file will probably not change the contents of ServoStyleConsts.h, meaning we can skip the rest of the DAG (this is done for all GENERATED_FILES). In comparison, changing mod.rs will both regenerate ServoStyleConsts.h, *and* force the style crate compile even if ServoStyleConsts.h is unchanged. Unfortunately there's no easy way to tell how likely or unlikely it is that a particular change will affect the output of a GENERATED_FILES script from the DAG, so this report is limited to taking a worst-case view and assumes that everything downstream needs to be updated. The idea behind the report was that we could quantify what we know anecdotally (ie: editing jsapi.h is annoying!) and consider the worst offenders for further investigation. It's entirely possible we'll determine that a file isn't as bad as the report indicates, or maybe we determine that a particular file is just always going to be bad because it would be a monumental task to split it up. I thought jsapi.h was going to fall into the latter group, so I'm glad to see jwalden and others tackle it! As that effort progresses, we should see jsapi.h fall down the list, and then perhaps we can use the new top offenders in the report to direct future efforts. - Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
