On 4/22/13 12:54 PM, Kartikaya Gupta wrote: > I looked at all the build.json files [4] from the 6th of April to the > 17th of April and pulled out all the jobs that corresponding to the > "push" changesets in my range above. For this set of 553 changesets, > there were 500 (exactly!) distinct "builders". 111 of these had "-pgo" > or "_pgo" in the name, and I excluded them. I created a 553x389 matrix > with the remaining builders and filled in how much time was spent on > each changeset for each builder (in case of multiple jobs, I added the > times). > > Then I assumed that any empty field in the 553x389 matrix was a result > of coalescing. This is a grossly simplifying assumption that I would > like to revisit - I know for Android changes we can detect that in some > cases and only run the relevant tests; my assumption means the rest of > the platforms are considered "coalesced" for these changes. I filled in > these fields in the matrix with the average time spent on all the other > builds for that builder in the matrix. > > * A total of 228717299 seconds were spent on the 128777 entries in the > matrix > * After de-coalescing, a total of 373751505 seconds would have been > spent on the 215117 entries in the matrix (an increase of 63%) > * With coalescing, but removing all the backout pushes and pushes that > were completely backed out, a total of 173027517 seconds were spent on > 97623 entries (down 24% from actual usage) > * With de-coalescing AND stripping backouts, a total of 292634211 > seconds would have been spent on the 168437 entries (an increase of 27% > over actual usage)
Too many iffy things to say that those percentages are anything other than numbers between 1 and 100, I'm afraid. Not only do Android-only pushes only build Android, b2g-only pushes only build b2g, and browser/-only pushes only build desktop, and jobs with spidermonkey in the name are only built for pushes that touch js/src/. You can tell the difference between coalescing and intentionally only building one product by looking at self-serve, where a push that only intended to build Android will only list the Android builds, while a push that intended to build everything but had everything but Android coalesced away will still show all the other builds, even though they actually ran on a different push, so I presume there's a way to query buildapi to find out whether a missing build was coalesced or just not triggered at all. Your range, April 6 - April 17, includes two full weekends (when coalescing barely exists) but only a week and a half of weekdays, when coalescing actually happens. It also includes the travel weekend before, and a half week of a b2g workweek when b2g patches were first not landing at all, and then landing on birch instead of inbound, dropping coalescing, but because birch granted itself the second-highest possible priority, coalescing could also have be more extreme on inbound while birch was starving it of slaves. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
