1145956 - Viewing huge patch in Bugzilla splinter's diff pegs CPU and hangs browser.

Status: UNCONFIRMED

(Core :: Layout, defect)

Description

[grunweg]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.5.0
Build ID: 20150225052701

Steps to reproduce:

Open a new tab, enter https://bugzilla.mozilla.org/attachment.cgi?id=8580812&action=diff into the URL bar, press Enter to load.



Actual results:

After a few seconds, my browser becomes totally unresponsive, consuming close to 100% CPU (on a dual-core machine), with memory usage ballooning, increasing as much as to 1.8GB.
I have to kill the firefox process in order to use my browser again.


Expected results:

Throughout the page loading, I can still use my browser.
Ideally, Firefox wouldn't even consume that much memory and CPU.

Comment 1

[grunweg]

Note that this should clearly be not a I/O or memory problem - I have 16GB of RAM and an SSD.

Comment 2

[[:Aleksej]]

firefox-31.0esr.en-US.linux64
36.0.4
2015-03-23-03-02-03-mozilla-central-firefox-39.0a1.ru.linux-x86_64

It takes 30-35 seconds to load here, and Firefox works properly after that.
RAM usage is about 1 GB more with the page loaded.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Just so we're all on the same page, that particular link produces 40MB of HTML output.  The typical memory cost of a DOM is 10x the original HTML source, so I'm not terribly surprised that loading this takes a lot of memory.

Over here, I do see the browser remaining fairly responsive throughout the the load, except for a 3-4 second pause during a layout pass.

Looking at about:memory with the page loading shows no particular surprises: about 900MB of memory for that page, with 460MB of DOM nodes (about 255MB element nodes and 205MB of textnodes) and 420MB of layout objects, breaking down like so:

  105MB -- blocks
   95MB -- border-collapsed table cells
   63MB -- text
   30MB -- inlines
   26MB -- table rows
   45MB -- line boxes
   14MB -- tables, non-border-collapsed table cells, table row groups, table columns
   57MB -- everything else (including style data).

Also for scale, there are 2757925 DOM nodes on that page.  So that 460MB usage is about 167 bytes per node.  If we look at just elements, there are 1187682 of those, so 255MB means 215 bytes per element.  None of those numbers are particularly surprising.

In terms of interaction with the browser UI, e10s will fix things here.  In terms of interaction with the page, maybe something like Servo would, or maybe not.  In terms of just using less memory here... tough luck.

Comment 4

[[:Aleksej]]

> Over here, I do see the browser remaining fairly responsive throughout the the load, except for a 3-4 second pause during a layout pass.

Similar here if the page is loading in background.