Closed Bug 706957 Opened 13 years ago Closed 2 years ago

Firefox unusable for long period of time

Categories

(Core :: Layout, defect)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dvander, Unassigned)

References

()

Details

(Keywords: perf, testcase, Whiteboard: [Snappy:P3])

Attachments

(1 file)

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.
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]
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.
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.
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.
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
ccing some more people who may want to profile this.
Browser unusable for >1 minute, has test case, is reproduce-able. Why is this P3? Can we bump this up in priority?
(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.
> can we add telemetry for reflow times We already do for XUL documents; we could just expand it to everything, right?
test page down
Attachment #578426 - Attachment is patch: false
Attachment #578426 - Attachment mime type: text/plain → application/zip
Attachment #578426 [details] testcase is ~100k row table with one image per row
QA Whiteboard: qa-not-actionable

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 → --

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.

Attachment

General

Created:
Updated:
Size: