Open Bug 1145956 Opened 6 years ago Updated 6 years ago
Viewing huge patch in Bugzilla splinter's diff pegs CPU and hangs browser
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.
Note that this should clearly be not a I/O or memory problem - I have 16GB of RAM and an SSD.
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.
QA Whiteboard: [bugday-20150323]
Component: Untriaged → Layout
Product: Firefox → Core
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.
> 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.
You need to log in before you can comment on or make changes to this bug.