1904990 - Firefox uses 45-70% more memory than Chrome when playing a video

Status: NEW

(Core :: Audio/Video, defect)

Description

[Justin Link]

Steps to reproduce

1. Close all tabs and force stop the app
2. Open a new tab to play a video in Youtube. (I used https://m.youtube.com/watch?v=-ZeAr9ROO8w for my tests.)
3. Check the memory usage at various points via adb using "adb shell dumpsys meminfo".

Expected behavior

Total memory usage by Firefox processes would be lower and closer to total memory usage by Chrome processes.

Actual behavior

Firefox (org.mozilla.firefox package) uses 6 total processes when playing video: the main process, the gpu process, two "tab" processes (one of which is the content process and the other of which is the extension process), a utility process and a media process. I ran this test twice for Firefox and got pretty consistent results. Here are the averages across those runs, per-process:

RSS:
  453,206K: org.mozilla.firefox:gpu (pid 20168)
  434,658K: org.mozilla.firefox (pid 20003 / activities)
  325,544K: org.mozilla.firefox:[content process] (pid 20101)
  181,432K: org.mozilla.firefox:[extension process] (pid 20337)
  136,628K: org.mozilla.firefox:utility (pid 20412)
  122,866K: org.mozilla.firefox:media (pid 20504)
-----------
1,654,334K

PSS:
  310,491K: org.mozilla.firefox:gpu (pid 20168)
  239,186K: org.mozilla.firefox (pid 20003 / activities)
  171,872K: org.mozilla.firefox:tab34 (pid 20101)
   43,996K: org.mozilla.firefox:tab15 (pid 20337)
   20,549K: org.mozilla.firefox:utility (pid 20412)
   14,002K: org.mozilla.firefox:media (pid 20504)
-----------
  800,096K

Chrome (com.android.chrome) uses 3 total processes when playing this same video: the main process, a gpu process and a content process. I ran this test three times for Chrome and got pretty consistent results as well. Here are the averages across those runs, per-process:

RSS:
  397,681K: com.android.chrome (pid 20018 / activities)
  303,444K: com.android.chrome:privileged_process0 (pid 20104)
  271,611K: com.android.chrome:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1 (pid 20189)
  --------
  972,736K

PSS:
  230,423K: com.android.chrome (pid 20018 / activities)
  168,191K: com.android.chrome:privileged_process0 (pid 20104)
  155,149K: com.android.chrome:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1 (pid 20189)
  --------
  553,763K

According to these numbers, Firefox is using about 70% more memory according to RSS accounting and 44% more memory according to PSS accounting when playing this video.

Device information

• Firefox version: 127.0.1
• Android device model: Pixel 6
• Android OS version: 14

Any additional information?

I'm not sure how important is was but, prior to running tests in a given browser, I closed all tabs in that browser, cleared the cache for that browser and restarted my device.

Comment 1

[Justin Link]

I've looked a little deeper into the GPU processes here since I'm thinking that those might be the simplest to analyze and compare.

From looking at the the more detailed breakdown from adb shell dumpsys meminfo <process>, most of the memory usage attributed to the GPU processes (from both browsers) is coming from the "EGL mtrack" and "GL mtrack" categories and most of the memory usage difference is coming from those same categories, particularly the latter. This is the case even for a more simple scenario - the mobile version of the wikipedia home page. I will attach the whole memory stats for each browser for each of those scenarios.

According to this, "GL mtrack is driver-reported GL memory usage. It's primarily the sum of GL texture sizes, plus fixed global driver RAM overheads."

Do we have any a priori expectation that Firefox would need to hold on more driver-managed memory than Chrome would?

Anecdotally, when I've seen other memory reports posted the EGL and GL mtracks are in roughly the same "ballpark" of each other so, in this sense, Firefox seems to be the outlier in having a much larger GL mtrack value than EGL mtrack value.

Could there be some graphics resource that we're not managing/cleaning up properly?

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Justin Link]

Some further information on graphics memory usage in this scenario.

Comment 4

[Jamie Nicol [:jnicol] (on leave until 21st October)]

Perhaps the Android Studio memory profiler can help track down these allocations. (I think maybe perfetto can also be used, and perhaps is being used by android studio under the hood, but I've only used android studio for this in the past)

Comment 5

[Justin Link]

(My previous comment was accidentally sent prematurely)

Regarding graphics memory usage, jrmuizel had suggested that I compare the numbers (EGL mtrack and GL mtrack, as mentioned above) that I'm seeing via adb shell dumpsys meminfo org.mozilla.firefox:gpu so I did that and reported it on perf-mobile. In summary, about:memory was showing about 100MB less usage in "textures" than the sum of EGL mtrack and GL mtrack.

When I mentioned that Firefox was pausing the video when switching to the about:memory tab and that this could be impacting the numbers that I'm getting padenot had suggested via Matrix that I install an extension that would allow youtube videos to play even when I have switched to another tab. After installing that extension, I am now seeing that the sum of "EGL mtrack" and "GL mtrack" is in the same ballpark as what is shown in the "textures" section under the GPU process (both around 220-230MB).

That's good news because it implies that there isn't some significant gap in what we're tracking/counting for this memory usage. It's still much higher than what Chrome is using for the same functionality, however.

At this point I think it makes sense to spin off the graphics memory usage difference when playing a video into its own bug and to continue looking at memory usage differences outside of graphics.