Noticed that Firefox is way slower than other browsers performing some fractal calculations.

While investigating, it has been found that prepending a try-catch block anywhere before the heavy calculations would make FF compete with others.

Running test-case.html on my machine, I get

no try catch: > 1000ms
with try catch: < 200ms

This is a regression, and searching for a range I found this pushlog which is linked to bug 1607986.

Ps: Note that for simplicity the attached test case builds the Functions on the fly, but whatever the execution context the same would happen (original case is more complicated and running in multiple Web-Workers).

Nice test case!

There are actually two regressions: bug 1607986, as already determined through mozregression, but also bug 1382650.

Bug 1382650 added another Ion optimisation level, which for the given test case modifies the OSR points. The additional OSR point leads to generating Phi nodes without proper type information, which then leads to returning early in IonBuilder::binaryArithTrySpecializedOnBaselineInspector. To fix the bug 1607986 regression, we simply need to remove that if-condition and instead handle the string case for which it was added in BaselineInspector. The bug 1382650 regression is probably more difficult to fix and therefore is unlikely to happen with the current WarpBuilder plans.

Btw, the reason adding try-catch avoids the regression, is that try-catch blocks modify when to apply OSR.

Jan, WarpBuilder is slow for the function containing the try-catch block. Is that a known limitation for the current prototype?

(In reply to André Bargull [:anba] from comment #2)

Jan, WarpBuilder is slow for the function containing the try-catch block. Is that a known limitation for the current prototype?

Good catch. The problem is that WarpBuilder skips the try-catch block but WarpOracle doesn't and it aborts on the JSOp::Exception. I'll post a patch for that. With that fixed I get about the same number for both.

https://hg.mozilla.org/mozilla-central/rev/3e654bf7a1e6

It would be good to uplift this patch to beta considering the potential perf impact while the fix is quite simple.

The patch landed in nightly and beta is affected.
:anba, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment on attachment 9153767 [details]
Bug 1642067: Use Baseline inspector to decide if strings can occur in binary arithmetic expressions. r=jandem!

Beta/Release Uplift Approval Request

• User impact if declined: Performance regression in (nested) loops.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Modifies when to apply a specific optimisation. Prior to this patch, the optimisation was disabled in too many cases, leading to use the slow fallback code. With this patch, the optimisation is taken based on the actual variable types seen at runtime, instead of using the types computed by Ion, which can be too pessimistic.
• String changes made/needed:

Comment on attachment 9153767 [details]
Bug 1642067: Use Baseline inspector to decide if strings can occur in binary arithmetic expressions. r=jandem!

approved for 78.0b5

https://hg.mozilla.org/releases/mozilla-beta/rev/61b74e5ef25b