Open Bug 771822 Opened 8 years ago Updated 5 years ago

slow rendering of large tables

Categories

(Core :: Layout: Tables, defect)

13 Branch
x86
Linux
defect
Not set
normal

Tracking

()

People

(Reporter: fry.kun, Unassigned)

References

Details

(Whiteboard: [leave open])

Attachments

(5 files)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120616215613

Steps to reproduce:

Opened a webpage with a large table (~10,000 rows)


Actual results:

Rendering took 5 seconds (original page took 12-20 seconds!)


Expected results:

Rendering should not take this long, other browsers (Chromium, Opera) take ~2 seconds to render the same page (original page takes ~5sec in Chromium)
Component: Untriaged → Layout: Tables
Product: Firefox → Core
The page generated by that script takes about 2.5 seconds to render for me over here.  Chrome took about 1.5 seconds.  Opera took about 2 seconds.

Note that Chrome has different rendering here (doesn't line-wrap the URLs), which allows it to be slightly faster at a loss in readability....

In any case, the obvious thing that jumps out at me from the profile is that we have both a refresh tick doing reflow and a nsGfxScrollFrameInner::AsyncScrollPortEvent::Run.  roc, what's that last about?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oh, and reflow is 60% of the pageload.  Frame consruction is another 16%.  vm_fault is another 12%.  Parsing is 4%.

Oh, 1/6 of the reflow time is invalidation.  So dlbi would help some....
Depends on: dlbi
(In reply to Boris Zbarsky (:bz) from comment #1)
> In any case, the obvious thing that jumps out at me from the profile is that
> we have both a refresh tick doing reflow and a
> nsGfxScrollFrameInner::AsyncScrollPortEvent::Run.  roc, what's that last
> about?

When an element starts/stops overflowing in a given direction, we post a DOM event named "overflow" or "underflow". Probably it would be better to dispatch those off the refresh driver via AddWillPaintObserver() as in PostScrollEvent(). Do you want to write the patch or shall I? :-)
The reason it does a flush is that FireScrollPortEvent has to decide whether to fire an event at all and which kind of event to fire, and that requires layout information.
Ah, that event.  Right.

If you want to write the patch, please go for it!  I'm totally swamped for the next several weeks.  :(  I can review, though!
I don't know if this will make much difference to the benchmark, but it should reduce the amount of layout flushing (since PresShell::WillPaint does a layout flush itself as well). Note that WillPaintObservers do run eventually, via a timer, even if the presshell is never painted.
Assignee: nobody → roc
Attachment #640931 - Flags: review?(bzbarsky)
Comment on attachment 640931 [details] [diff] [review]
use WillPaintObserver

r=me, but it doesn't seem to help much on the actual testcase.  :(
Attachment #640931 - Flags: review?(bzbarsky) → review+
Is this patch present in Fx15 release?
Testcase takes ~3sec - slower than Chromium 20 and Opera 11 (~1.5s for both)
Note: using a new laptop, so don't compare it to original report of 5sec.. :)
The patch that was checked in is going to be in Firefox 16.  You can try a beta if you want to see it.  But note comment 7 and the fact that this bug is still open.  ;)
Just a note: I see this slow rendering of a table with a 366KB HTML e-mail, so the
table doesn't have to be very large.  This is much slower than TBird 14.

TBird 15.0
Linux Fedora 16 64bit.
CPU=12@3.20GHz
Mem=12GB
Addons:
  Enigmail 1.4.4
  Exchange 2007/2010 Cal and Tasks provider 1.8.5
  Lightning 1.7
  Provider for Google Cal 0.16
  Remove Duplicate Messages (Alternate) 0.3.7
  Test Pilot for Thunderbird 1.3.9
  ThunderBrowse 3.81
Theme: Default 15.0
Tested again on new hardware and OS (Fedora 18 x86)

Firefox 25 -- takes ~4 seconds (UI is frozen until whole page is rendered; no part of the table is displayed until 4sec)
Chromium 27: visible part of table displayed after ~1sec, page done loading after ~3sec
Midori 0.4.7: visible part displayed after ~1sec, page done after ~7sec
Opera 12.16: entire page is rendered after ~2sec
Konqueror 4.10.5: visible part is displayed after ~1sec, entire page after ~4sec
Fedora 20, kernel 3.12.6-300.fc20.x86_64

Firefox 26 still takes ~4sec with completely frozen UI ("page loading" spinner doesn't spin, etc.)

Anyone investigating?
I just hit this with Firefox 37.0.1 .   I can replicate using our web page, and the attached test case on OpenSuSE 13.1.   Gecko seems 2x as slow as WebKit for rendering large data tables.
The issue is still present, here's a real-world example -- an 8MB webpage generated by a program that doesn't know that it shouldn't do that..
The original page (with JS and CSS includes) takes >1min to display on reasonably modern hardware; the attached HTML-only version takes "just" 15 seconds in comparison.

There's definitely room for optimization, I wish someone would get on it...
The attached HTML-only version from comment 16 loads in 3s for me on a modernish laptop, for what it's worth.  At least from a file:// URL.  About 2x faster than Chrome, also for what it's worth.
Attached file performance profile
Just re-tested it in a clean profile -- takes 5 seconds to load. I guess the other 10sec are thanks to addons... sorry about that
During those 5sec, browser appears frozen. Chrome, however, shows top of the page in less than a second -- but continues to render the rest of the page for a while. Are you also testing on linux?

Here's a performance recording for a full page, however (in clean browser profile) -- does that look normal?
Same page load, but with OMTC enabled
Note: previous comment mentioned OMTC -- that refers to layers.acceleration.force-enabled=true
You need to log in before you can comment on or make changes to this bug.