1964262 - Testcasing importing empty JS modules using blobs blocks 24s on the parent-process and 4s in Timer thread. Chrome is instant. (N=50k)

Status: NEW

(Core :: DOM: File, defect)

Description

[Mayank Bansal]

Attachment: js modules_asyncawaittime.HTML

Open testcase
Enter 50000 and press on the button

Firefox: https://share.firefox.dev/430pnHo (34s in total
Chrome: https://share.firefox.dev/3SlAGoG (dont even see any blips with 10x the loopcount)

Not sure where this bug should go. Tentative filing in XPCOM.
cc folks involved in timers, blobs and js modules.

Comment 1

[Mayank Bansal]

Attachment: js modules_simple loop.HTML

this is the same testcase but without any promises, await,async, or delays (I hope).
We are basically infinitely faster here. Chrome keeps on loading teh testcase.

N=500k
Firefox: https://share.firefox.dev/42SgyRr (70s. includes reloading and cleanup)
Chrome(Partial): https://share.firefox.dev/4k2A6YU (330s+)

Comment 2

[Jens Stutte [:jstutte]]

(In reply to Mayank Bansal from comment #0)

Firefox: https://share.firefox.dev/430pnHo (34s in total

There is a piece of TimerThread (bug 1961386) here (~10%) but the main culprit seems to be RevokeURIs which is the payload of a timer.

(In reply to Mayank Bansal from comment #1)

N=500k
Firefox: https://share.firefox.dev/42SgyRr (70s. includes reloading and cleanup)

And indeed here we do not see the TimerThread involved and thus much less calls to RevokeURIs. Note the much higher number of iterations.

Comment 3

[Jens Stutte [:jstutte]]

Assuming that such a high number of blobs is rarely to be seen in the wild.

Said that, our way of using gDataTable could really benefit from some improvement. It seems we have at least three different ways of finding entries:

• via a hashtable Get based on the URI
• via a linear walk looking for mRevokeId
• via a linear walk looking for mContentParentId

and the latter two are clearly not scaling well.