Closed Bug 1642067 Opened 1 month ago Closed 1 month ago

Performance regression in calculating fractals, influenced by try-catch block

Categories

(Core :: JavaScript Engine: JIT, defect, P1)

76 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox-esr68 --- unaffected
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- fixed
firefox79 --- fixed

People

(Reporter: tristan.fraipont, Assigned: anba)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Attached file test-case.html

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).

Flags: needinfo?(evilpies)
Keywords: regression
Regressed by: 1607986

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.

Assignee: nobody → andrebargull
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(evilpies)
Regressed by: 1382650

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

Flags: needinfo?(jdemooij)

(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.

Flags: needinfo?(jdemooij)
Pushed by abutkovits@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3e654bf7a1e6
Use Baseline inspector to decide if strings can occur in binary arithmetic expressions. r=jandem
Severity: -- → S3
Priority: -- → P1
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79

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.

Flags: needinfo?(andrebargull)

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:
Flags: needinfo?(andrebargull)
Attachment #9153767 - Flags: approval-mozilla-beta?

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

Attachment #9153767 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.