On Wed, Aug 29, 2018, at 9:08 AM, Boris Zbarsky wrote: > > https://taskcluster-artifacts.net/CLtUuQugTjKONONL4hh5Nw/0/public/14day_report.html > > So my main conclusion from looking at this data is that anything that > causes us to rebuild any rust stuff is just painful...
I don't think that's *entirely* the case, but it's certainly not far off. The first thing to note is that all of this data is derived from the tup build database, so it's possible that there are things here that are artifacts of our tup build implementation. The #1 item on that list is Cargo.lock, which is there because it was changed 8 times in 14 days and a lot of work happens if you change it. In the general case, updating a crate version should only cause us to rebuild everything in its dependency tree, but I don't know if: a) The tup build does unnecessary work in cases where crates are updated but it shouldn't need to rebuild things like gkrust. The cargo build plan integration is pretty new, so it's possible it has some rough edges. This is worth looking into! b) What crates are actually being updated. This data ought to be easy to get. If we are in fact regularly updating crates that get compiled into gkrust then yeah, we're probably going to have a bad time. The source files under servo/components/style/gecko/ seem to be responsible for a fair amount of churn, which I assume is mostly "the style crate is expensive to compile" + "these are the source files in the style crate that get changed frequently". Obviously folks have put a lot of work into making the Rust compiler faster, but there may be other changes to the style crate that could mitigate this, like splitting it into sub-crates so that not all of the code needs to get rebuilt every time. Additionally, this data doesn't take rustc's incremental compilation feature into account--if you have a previously-built objdir and you pull in some new changes that touch those source files rustc ought to be able to compile the style crate more quickly than it would for a clean build. It would probably be useful to enhance this report with a way to drill down and find out *why* a particular file is so expensive, like "what set of things get rebuilt if you touch this file?" That might wind up being overly-verbose in the case of things like jsapi.h that gets included in a zillion source files, but maybe we can figure out a useful summary. -Ted _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
