1943729 - Testcase generating 100K webcodec elements takes 1 minute to destroy if you reload it in the background

Status: RESOLVED INCOMPLETE

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

Description

[Mayank Bansal]

Attachment: Webcodec.HTML

Open the attached testcase
Enter 100000 and press generate
Wait for it to get generated
Open a new tab in foreground (such that the testcase tab is in the background)
Right Click on the testcase tab and click on "Reload Tab"

AR: The page takes 55 seconds around CC
ER: Not so maybe?

Nightly
Create: https://share.firefox.dev/4aykmJE (12 seconds)
Reload: https://share.firefox.dev/3WzFIQZ (55 seconds)

Chrome
Create: OOMs in generation

I generated thsi testcase using chatgpt. This is an artificial testcase. Feel free to WONTFIX/INVALID.

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Paul Adenot (:padenot)]

I think this is more or less expected. When creating, you just create. When reloading, you need to clear all the garbage of the previous page, and create, this is very slow.

Andrew, this is a stress case. If framed like this, do you think that the behaviour observed is more or less reasonable? In "real-life", the cardinality of the various objects in an application, even quite involved, could be maybe be a hundred (stretching it a bit, but you never know).

Comment 3

[Mayank Bansal]

The page doesnt create anything on reload (that is, the default is to generate 0 elements).

Comment 4

[Andrew McCreight [:mccr8]]

From the second profile, this isn't really "cycle collection". This is running the destructor for HTMLMediaElement.

The time seems to be spent almost entirely inside addref and release calls that are inside nsDefaultComparator<nsMaybeWeakPtr, nsObserver*>::Equals() that is getting run inside nsObserverList::RemoveObserver. It looks like the basic problem is that there's no way to directly compare them, so the nsObserver* implicitly converted to a nsMaybeWeakPtr, which does an addref, then later a release when we destroy the temporary object. This could still be slow, but surely we could speed that up.

Anyways, we should probably improve that, but your test case involves running an expensive operation in a background tab, and we intentionally deprioritize processes only containing web pages that are running in the background, so this is also fundamentally things working the way they are supposed to.

Comment 5

[Mayank Bansal]

(In reply to Andrew McCreight [:mccr8] from comment #4)

Anyways, we should probably improve that, but your test case involves running an expensive operation in a background tab, and we intentionally deprioritize processes only containing web pages that are running in the background, so this is also fundamentally things working the way they are supposed to.

In most (all?) cases where I reload the generated testcase in the foreground tab with the profiler running, the memory does not get cleared. In fact, if you reload it even once in the foreground, it basically means that the memory will never be released even if you then subsequently reload it in the backgground. It will only get released if you close the tab.
30000 elements
Reloading in foreground: https://share.firefox.dev/3CoNDtJ . The memory did not decrease. (full profile is 3m20s+ long. Truncated version here due to size)
Reloading in background: https://share.firefox.dev/4jLTSIW . Memory got cleared.

Comment 6

[Mayank Bansal]

Andrew, ni? for the observation in comment 5 that while the profiler is running and then reloading the generated tab in the foreground does not release memory in many instances.

Comment 8

[Andrew McCreight [:mccr8]]

I don't think we really care about performance in a background tab. We intentionally deprioritize it. It isn't really "wontfix" or "invalid" so I'll just mark it incomplete.

Comment 9

[Mayank Bansal]

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