1948535 - Testcase generating N serviceWorkers is 6x slower than Chrome. With 10x the service workers, Nightly is 45x slower

Status: RESOLVED DUPLICATE of bug 1950873

(Core :: DOM: Service Workers, enhancement)

Description

[Mayank Bansal]

Attachment: ServiceWorker.HTML

Open attached testcase.
Enter a number and press enter.

50K

• Chrome: https://share.firefox.dev/41h2qQH (262ms)
• Nightly: https://share.firefox.dev/4hKPHvp (1.8s)

500K

• Chrome: https://share.firefox.dev/4k47D5Y (2.5s)
• Nightly: https://share.firefox.dev/4k2tElj (112s)

This is an artificial testcase. Maybe this suggests some hotspots in our code? As always, feel free to close as INVALID/WONTFIX.

Comment 1

[Mayank Bansal]

Attachment: ServiceWorke_no error handling.HTML

removed teh try-catch thingy. No difference in relative difference. I have the laptop on battery now so the numbers are slightly higher.

50k
Chrome: https://share.firefox.dev/3D5UzvU (300ms)
Nightly: https://share.firefox.dev/3X2Cg1J (2.2s)

Comment 2

[Mayank Bansal]

Can repro on a build from Jan2022, so not a new regression.

Comment 3

[Jens Stutte [:jstutte]]

IIUC the test is not about (service) workers being slow, but mostly about promise rejections being potentially very slow if we have many of them. The test uses a script that does not exist on worker creation, which causes us to reject the promise (there seems to be some overhead inside mozilla::dom::ServiceWorkerScopeAndScriptAreValid until we understand that) which then makes them pile up and most likely cause some quadratic runtime inside JSRuntime::removeUnhandledRejectedPromise.

I assume one could rewrite the test, just creating a promise that rejects itself immediately to isolate better that specific case. I have no idea if that indicates some problem that might go beyond this very ill edge case. For example if we resolve a huge amount of promises instead (which could happen more likely in the wild?).

Comment 4

[Mayank Bansal]

(In reply to Jens Stutte [:jstutte] from comment #3)

IIUC the test is not about (service) workers being slow, but mostly about promise rejections being potentially very slow if we have many of them. The test uses a script that does not exist on worker creation, which causes us to reject the promise (there seems to be some overhead inside mozilla::dom::ServiceWorkerScopeAndScriptAreValid until we understand that) which then makes them pile up and most likely cause some quadratic runtime inside JSRuntime::removeUnhandledRejectedPromise.

Based on this, I will dupe it to Bug 1950873. But please undupe if you disagree!