Closed Bug 1943735 Opened 22 days ago Closed 18 days ago

Testcase that generates large number of webrtc elements take 4:45 minutes around CC if you reload it in the background

Categories

(Core :: Audio/Video: Playback, defect)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1943729

People

(Reporter: mayankleoboy1, Unassigned)

References

Details

Attachments

(2 files)

Attached file Webrtc.html

Open the attached testcase
Input 250000 in the box and click on generate
Wait for the element to generate. We do pretty good here compared to Chrome
Now reload the page using the reload button on the browser toolbar

Profile: https://share.firefox.dev/40wxOJn (4:45 minutes)
Chrome doesnt generate these many elements. But on a smaller testcase (50000), the reload speed is basically instant for Chrome, whereas it takes 13 seconds for us.
So we generate the elements faster, but take longer to reload the page. Make what you will of this.

Maybe there is something to improve here?

This is an artificial testcase that I created with chatgpt. Feel free to WONTFIX/INVALID.

Attached file about:support
See Also: → 1943230

Wow, that's actually rendering really smooth once the dust has settled. It seems like main thread is what is crumbling.

Out of your 4m45s about 4m30s is a single CC's ForgetSkippable.

If reload is fast in Chrome maybe it's because they fire up a new content process? (I don't know if they do, but that would explain not needing to wait for a final CC).

Doesn't seem like a webrtc issue, so moving to the CC component in case there is something we could do there. After all, it's an extremely artificial test case.

Type: enhancement → defect
Component: WebRTC → Cycle Collector

Bug 1944426 may fix this too.

See Also: → 1944426

(In reply to Andreas Pehrson [:pehrsons] from comment #2)

Out of your 4m45s about 4m30s is a single CC's ForgetSkippable.

The relevant thing here is not the ForgetSkippable, it is the ~HTMLMediaElement. We're just destroying a bunch of garbage media elements.

That being said, I don't think we care about performance in a background tab, and it does appear to be the same problem as would be addressed by bug 1944426 .

Component: Cycle Collector → Audio/Video: Playback
Status: NEW → RESOLVED
Closed: 18 days ago
Duplicate of bug: 1943729
Resolution: --- → DUPLICATE
See Also: 1943729

This is what i get now: https://share.firefox.dev/4jMOTaL

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: