Closed
Bug 706957
Opened 13 years ago
Closed 2 years ago
Firefox unusable for long period of time
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: dvander, Unassigned)
References
()
Details
(Keywords: perf, testcase, Whiteboard: [Snappy:P3])
Attachments
(1 file)
(deleted),
application/zip
|
Details |
On the given URL, Firefox is unusable for over a minute while it tries to render the page. This page is a reduced test case a user sent me, based on an internal company app. Chrome not only loads the page faster, but the UI is responsive in the interim.
https://crash-stats.mozilla.com/report/index/bp-055ac669-5cd9-4487-a1d8-e1c472111201
I got this loading view-source:http://devicenull.org/fftest2.html in safe mode
Depends on: 318474
At the link without view-source:
https://crash-stats.mozilla.com/report/index/bp-26d32a85-370d-4c23-85c0-55c692111201
Comment 3•13 years ago
|
||
I was gonna say this bug needs more data, but then I clicked on the link in comment 2, firefox became unresponsive and when i tried to close the tab, it crashed.
Boris, does this sound like a low priority snappy bug or should we make this a higher priority one since it also involves a crash?
Whiteboard: [Snappy] → [Snappy:P3]
Comment 4•13 years ago
|
||
Those "crashes" are from the hang detector. Pretty much expected for a very laggy testcase if the hang detector is enabled, right?
dvander, how stable is that URI? Can you attach the testcase to the bug?
For Chrome, of course, the UI can be responsive even if the page is completely hung.... that's our real issue here.
Reporter | ||
Comment 5•13 years ago
|
||
bz: the URI is stable, but I'll attach to be safe. Yes, the frozen UI is the real issue, but also the page loads much, much faster in Chrome.
Reporter | ||
Comment 6•13 years ago
|
||
Comment 7•13 years ago
|
||
Profile says time mostly spent under table reflow, unsurprisingly. No single-function hotspot, though about 30% of the time is under invalidation in the one profile I did.
Note that doing a full frame reconstruct and relayout on the page once it's loaded takes about 50s for me; a good bit of that in a little slice profile I just did for 3-4 seconds is textrun creation....
Overall, the real issue here is that incremental rendering makes this all O(N^2) but even the O(N) part is tens of seconds long.
Comment 8•13 years ago
|
||
I believe Chrome just gives up on incremental rendering for large pages, by the way. But that 50s reframe+reflow time worries me...
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Comment 9•13 years ago
|
||
ccing some more people who may want to profile this.
Comment 10•13 years ago
|
||
Browser unusable for >1 minute, has test case, is reproduce-able.
Why is this P3? Can we bump this up in priority?
Comment 11•13 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #8)
> I believe Chrome just gives up on incremental rendering for large pages, by
> the way. But that 50s reframe+reflow time worries me...
Boris, can we add telemetry for reflow times so we know how much a problem this kind of usecase is in the wild? Perhaps this should be a Snappy:P1, but without data it's hard to know if this is an exceptional usecase.
Comment 12•13 years ago
|
||
> can we add telemetry for reflow times
We already do for XUL documents; we could just expand it to everything, right?
Comment 13•8 years ago
|
||
test page down
Updated•8 years ago
|
Attachment #578426 -
Attachment is patch: false
Attachment #578426 -
Attachment mime type: text/plain → application/zip
Comment 14•8 years ago
|
||
Attachment #578426 [details] testcase is ~100k row table with one image per row
Severity: normal → major
Comment 15•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Severity: major → --
Comment 16•2 years ago
|
||
Profile recorded today with the attached zip:
It's ~16 seconds until we're done loading: https://share.firefox.dev/3IcDTSQ
Chrome takes about the same amount of time.
In WebKit (epiphany), the UI locks up and it never finishes loading the testcase (I gave it about a minute).
So (at least on modern hardware) we're much better than we used to be, and it's not clear there's any performance gap to be closed here vs. the competition.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•