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 making them 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?).
Bug 1948535 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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?).