Closed Bug 1578386 Opened 5 months ago Closed 5 months ago

2.72 - 11% raptor-wasm-misc-baseline-firefox / raptor-wasm-misc-firefox / raptor-wasm-misc-ion-firefox (linux64-shippable, linux64-shippable-qr) regression on push eee3b548e7cd4757d7611ec319aabcea8bf3c2df (Sat August 31 2019)


(Core :: Javascript: WebAssembly, defect)

Not set



Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox69 --- unaffected
firefox70 --- fixed
firefox71 --- fixed


(Reporter: Bebe, Assigned: rhunt)


(Blocks 1 open bug, Regression)


(Keywords: perf, regression)

Raptor has detected a Firefox performance regression from push:

As author of one of the patches included in that push, we need your help to address this regression.


11% raptor-wasm-misc-ion-firefox linux64-shippable opt 39,595.71 -> 43,952.00
11% raptor-wasm-misc-firefox linux64-shippable-qr opt 39,709.53 -> 43,974.60
11% raptor-wasm-misc-firefox linux64-shippable opt 39,729.51 -> 43,977.49
3% raptor-wasm-misc-baseline-firefox linux64-shippable-qr opt 69,790.92 -> 71,689.90

You can find links to graphs and comparison views for each of the above tests at:

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a Treeherder page showing the Raptor jobs in a pushlog format.

To learn more about the regressing test(s) or reproducing them, please see:

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations:

Blocks: 1578356
Regressed by: 1518210
Component: Performance → Javascript: WebAssembly
Flags: needinfo?(rhunt)
Product: Testing → Core
Version: Version 3 → unspecified

Interesting, could indicate that the test machine gets the explicit bounds checking path?

I think the issue resolved by bug 1578031 is a more likely candidate. It would cause us to fold all offsets > 1, which seems like it would have a performance impact.

Flags: needinfo?(rhunt)

Oh, and bug 1507765 (the work to actually dynamically turn off huge memory with low VM limits) hasn't landed yet. So we definitely shouldn't unintentionally be getting explicit bounds checks on these machines.

== Change summary for alert #22942 (as of Tue, 03 Sep 2019 12:56:41 GMT) ==


10% raptor-wasm-misc-firefox linux64-shippable opt 44,064.13 -> 39,739.46
10% raptor-wasm-misc-ion-firefox linux64-shippable opt 43,917.87 -> 39,609.96
10% raptor-wasm-misc-ion-firefox linux64-shippable-qr opt 43,930.73 -> 39,677.87
9% raptor-wasm-misc-firefox linux64-shippable-qr opt 43,835.86 -> 39,999.05
2% raptor-wasm-misc-baseline-firefox linux64-shippable opt 71,504.26 -> 69,756.17
2% raptor-wasm-misc-baseline-firefox linux64-shippable-qr opt 71,604.80 -> 69,951.33

For up to date results, see:

Closed: 5 months ago
Resolution: --- → FIXED

What actually fixed this?

Flags: needinfo?(rhunt)

Bug 1578031 actually fixed this issue.

Flags: needinfo?(rhunt)
Assignee: nobody → rhunt
Depends on: 1578031
Target Milestone: --- → mozilla71
Blocks: 1592626
No longer blocks: 1592626
You need to log in before you can comment on or make changes to this bug.