Open Bug 1949221 Opened 6 months ago Updated 18 days ago

Testcase generating N promises and immediately resolving them is 21x slower in Nightly

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files, 1 obsolete file)

Attached file promises.html

Open attached testcase
Enter N = 5000000
Press enter

Nightly: https://share.firefox.dev/415eof5 (16s)
Chrome: https://share.firefox.dev/41jfrJA (900ms)

Extremely unrealistic, but maybe something obvious to fix?
Unsure of the right BMO component, tentatively filing under JS as the profile suggests time spent in JS.

We have a fair bit of evidence from elsewhere (eg bug 1924185, bug 1902347) that our promise resolution is too slow. I'm not sure if it's all one issue or a mixture of different issues, but either way we should probably look into this at some point.

Priority: -- → P2

Some things I notice in this profile:

  • We have this "host defined data" object that we allocate in CycleCollectedJSContext::getHostDefinedData. This is a spec concept but in practice we only store the incumbent global in it. We could probably optimize this in our implementation and pass/store the incumbent global directly.
  • There's a lot of overhead for PromiseJobRunnable and PromiseJobCallback: JS holder map entries, cycle collection, etc. Maybe this could be optimized better if we (partially) moved the microtask queue into SpiderMonkey.

(In reply to Mayank Bansal from comment #3)

Created attachment 9468854 [details]
Promise- rejection.html

I think that's a different issue: quadratic behavior from linear lookups on large arrays in CycleCollectedJSContext::PromiseRejectionTrackerCallback. Probably the mAboutToBeNotifiedRejectedPromises and mUncaughtRejections arrays.

See Also: → 1950873
Attachment #9468854 - Attachment is obsolete: true

Filed bug 1950873 to track the promise-rejection case separately.

Blocks: sm-js-perf

N= 5000000

Firefox: https://share.firefox.dev/4id2Kpy (3.9s to geenrate, 1.2s to resolve)
Chrome: https://share.firefox.dev/3DeI1mi (1s to generate, 95ms to resolve)

N=5000000
With error handling: Generate and Resolve

With error handling: Generate and Reject

Try Build from this containing patches from bug 1953167

Testcase from Comment 0
N = 5000000
Firefox: https://share.firefox.dev/3Fylv8p (11s)

  • Improvement from 16s ->11s (31% improvement)

Testcase from comment 6
N= 5000000
Firefox: https://share.firefox.dev/43CFYDa (4.2s to generate, 1.1s to resolve)

  • Not much improvement

Testcase from comment 7
N= 5000000
Firefox: https://share.firefox.dev/3FxVN3W (8.8s to reject)

  • 7% improvement
Depends on: 1953167

Profile with latest Nightly: https://share.firefox.dev/4ipQnqm (13s + CC)

See Also: → 1954338

with latest Nightly containing the fix from bug 1953167:

Testcase from Comment 0
N = 5000000
Profile: https://share.firefox.dev/3FSyqSW (12s)

Testcase from comment 6
N= 5000000
Profile: https://share.firefox.dev/3Y9NXEc (4.2s to generate, 1.2s to resolve)

Testcase from comment 7
N= 5000000
Profile: https://share.firefox.dev/3DYAAQt (7s to geenrate, 9s to reject)

Testcase from Comment 0
N = 5000000

Blocks: 1980560
See Also: 1943230
Type: enhancement → defect
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: