Bugzilla

I'm baffled that this particular change here would cause a regression in those tests. A couple thoughts/questions came to mind:

1) @smolnar: In [the push with my change which has those failures](https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Crunning%2Cpending%2Crunnable&searchStr=nw&revision=335f67e8b5950e8cfb23327a701467b589a7df56) those tests are consistently taking longer to run than in [the push with my changes removed in which those tests don't fail](https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Crunning%2Cpending%2Crunnable&revision=abfe9884ce821653277d51273689ef8b507cffd3&searchStr=nw). Other tests in that same suite do not show this time discrepancy. The failures are also _only_ occurring on Windows 10 x64 2004 WebRender Shippable and, when they are failing, those tests are taking even longer than the same tests in the Windows 10 x64 2004 WebRender debug. Is it possible that those particular tests are running on a particular machine that is older/slower or that has something else going on with it to make it slow?
2) @jrediger: There is not much going on this change. The only "interesting" thing is really the call into glean to record the sample. Can you think of any conditions under which this could cause a performance problem? It seems to be only a couple tests and only on a highly-optimized configuration which is odd.
3) Does anybody know how to trigger these tests in a push-to-try? I did one and tried to find and select [everything that seemed related to Windows Shippable ](https://treeherder.mozilla.org/jobs?repo=try&resultStatus=retry%2Csuccess%2Ctestfailed%2Cbusted%2Cexception%2Crunning%2Cpending%2Crunnable&tier=3%2C2%2C1&revision=e524d938e770cced71e3daee79a41cddcdec4dcc&duplicate_jobs=visible) and, unless I'm missing something, it didn't run the "M-spi-nw" tests for that config (but they did run for some other configs).

I'm baffled that this particular change here would cause a regression in those tests. A couple thoughts/questions came to mind:

1) @smolnar: In [the push with my change which has those failures](https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Crunning%2Cpending%2Crunnable&searchStr=nw&revision=335f67e8b5950e8cfb23327a701467b589a7df56) those tests are consistently taking longer to run than in [the push with my changes removed in which those tests don't fail](https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Crunning%2Cpending%2Crunnable&revision=abfe9884ce821653277d51273689ef8b507cffd3&searchStr=nw). Other tests in that same suite do not show this time discrepancy. The failures are also _only_ occurring on Windows 10 x64 2004 WebRender Shippable and, when they are failing, those tests are taking even longer than the same tests in the Windows 10 x64 2004 WebRender debug. Is it possible that those particular tests are running on a particular machine that is older/slower or that has something else going on with it to make it slow?
2) @jrediger: There is not much going on in this change. The only "interesting" thing is really the call into glean to record the sample. Can you think of any conditions under which this could cause a performance problem? It seems to be only a couple tests and only on a highly-optimized configuration which is odd.
3) Does anybody know how to trigger these tests in a push-to-try? I did one and tried to find and select [everything that seemed related to Windows Shippable ](https://treeherder.mozilla.org/jobs?repo=try&resultStatus=retry%2Csuccess%2Ctestfailed%2Cbusted%2Cexception%2Crunning%2Cpending%2Crunnable&tier=3%2C2%2C1&revision=e524d938e770cced71e3daee79a41cddcdec4dcc&duplicate_jobs=visible) and, unless I'm missing something, it didn't run the "M-spi-nw" tests for that config (but they did run for some other configs).