Testcase generating N promises and immediately resolving them is 21x slower in Nightly
Categories
(Core :: JavaScript Engine, defect, P2)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
(Blocks 2 open bugs)
Details
Attachments
(3 files, 1 obsolete file)
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.
Comment 1•6 months ago
|
||
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.
Comment 2•6 months ago
|
||
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
andPromiseJobCallback
: JS holder map entries, cycle collection, etc. Maybe this could be optimized better if we (partially) moved the microtask queue into SpiderMonkey.
Comment hidden (obsolete) |
Comment 4•6 months ago
|
||
(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.
Reporter | ||
Updated•6 months ago
|
Reporter | ||
Comment 5•6 months ago
|
||
Filed bug 1950873 to track the promise-rejection case separately.
Reporter | ||
Updated•6 months ago
|
Reporter | ||
Comment 6•5 months ago
|
||
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)
Reporter | ||
Comment 7•5 months ago
|
||
N=5000000
With error handling: Generate and Resolve
- Firefox: https://share.firefox.dev/3Fb8Xnv (7.7s to generate, 8.5s to resolve)
- Chrome: https://share.firefox.dev/4i5vzEq (1.3s to generate, 240msto resolve)
With error handling: Generate and Reject
- Firefox: https://share.firefox.dev/4iwFNxp (9.5s to reject)
- Chrome: https://share.firefox.dev/4kvIctY (260ms to reject)
Reporter | ||
Comment 8•5 months ago
|
||
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
Reporter | ||
Comment 9•5 months ago
|
||
Profile with latest Nightly: https://share.firefox.dev/4ipQnqm (13s + CC)
Reporter | ||
Comment 10•5 months ago
|
||
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)
Reporter | ||
Comment 11•2 months ago
•
|
||
Testcase from Comment 0
N = 5000000
- Chrome: https://share.firefox.dev/3Zy0Bxw (700ms)
- Firefox with profiler: https://share.firefox.dev/3FYlxaq (11s)
- Firefox Samply: https://share.firefox.dev/4e250P8 (9.5s)
Reporter | ||
Updated•18 days ago
|
Description
•