Closed Bug 1279760 Opened 8 years ago Closed 8 years ago

Tremendous resource consumption upon loading the Satoshi Matrix Top 100 NES game list

Categories

(Core :: JavaScript Engine, defect)

48 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1284350
Tracking Status
firefox47 --- affected
firefox48 --- affected

People

(Reporter: kfm, Unassigned)

Details

(Whiteboard: [MemShrink])

Attachments

(2 files)

Attached file memory-report.json.gz
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160606200529

Steps to reproduce:

Load the following URL in Firefox 48.0b1 (win64):

https://satoshimatrix.wordpress.com/2012/03/23/top-100-nesfamicom-games-list-all-in-one/


Actual results:

The browser proceeded to consume ~1.3G of RAM. Further, casual observation of the Task Manager in Windows 10 attributed high CPU usage and protracted bursts of astonishingly high disk throughput to Firefox. Once the page had finished loading, CPU usage remained curiously high until things eventually settled. In my case, it took approximately 1 minute and 40 seconds from the time of entering the URL to the point of settlement.

Before launching Firefox, I removed %APPDATA%\Mozilla and %LOCALAPPDATA%\Mozilla, in order to ensure a clean slate and to allow for a clean memory usage dump. If I recall correctly, I first became aware of this issue in Firefox 46.0, only because it was the first occasion on which I had visited the site in question.


Expected results:

However bad the markup may be, Chrome handles the page with relative ease. I would hope for the resource consumption of Firefox to be reduced for this case.
20160604131506 Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
20160606200529 Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0

I have tested your issue on latest FF release 47.0, latest FF Beta 48.0b1 and managed to reproduce it. I have also tested on latest Nightly build 20160614030210 and could not reproduce it.(see attachment)

Please download the Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Ever confirmed: true
Whiteboard: [MemShrink]
This should move to the component that matches the memory consumption from the memory-report, not just default to Fx::General.
Component: General → Untriaged
Hi Gijs,

Can you give me a hand with this memory-report, from what I see my opinion is that this bug should fit in to Core: Dom. What do you think?
Flags: needinfo?(gijskruitbosch+bugs)
This happens everywhere, also on 49 and 50, but e10s might make it less noticeable there because the memory usage will be in the content process. The same thing happens on Chrome (and the memory usage ends up in the helper/content process like it does in e10s in Firefox). The reason is that the page embeds gazillions of youtube iframes, all of which source a bunch of stuff and take up about 6mb each (in the memory report attached here).

I don't know how much we can do to fix that, but yes, it's likely that core/dom is a non-terrible place for this.
Component: Untriaged → DOM
Flags: needinfo?(gijskruitbosch+bugs)
Product: Firefox → Core
Lets send this over to AV playback for triage. I think there might be some work underway to help with these types of sites.
Component: DOM → Audio/Video: Playback
(In reply to Eric Rahm [:erahm] from comment #5)
> Lets send this over to AV playback for triage. I think there might be some
> work underway to help with these types of sites.

To get video out of the equation, I tried setting:

media.mp4.enabled=false
media.webm.enabled=false

With Flash also not installed, it shows "Your browser does not currently recognise any of the video formats available" in the YouTube spots. This didn't seem to make a significant difference to jank or memory usage.

Given the number of images on this page I'm going to bounce it to ImageLib.
Component: Audio/Video: Playback → ImageLib
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #6)
> Given the number of images on this page I'm going to bounce it to ImageLib.

After finishing loading the page about:memory reports about 30mb taken by images, an entirely reasonable amount.

The biggest chunk of memory in about:memory is taken up by ~100 window objects each containing a youtube video and taking about 6mb each. Inside one such window the js-compartment is 4mb, stylesheets are 1mb, layout is 0.5mb, dom is 0.21mb. The js-zone is another 200mb. So for lack of a better place I'll put this in js.
Component: ImageLib → JavaScript Engine
This is likely a dup of bug 1284350.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Not really sure this is a dupe. Which is why I filed bug 1284350 after reading this bug in the first place. The STR only call for loading the page, not scrolling through it. And the memory report does not have large memory use by images.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: