771822 - slow rendering of large tables

Status: NEW

(Core :: Layout: Tables, defect)

Description

[Konstantin Svist]

Attachment: python script to generate a 10,000 line table in html file

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)

Comment 1

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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? :-)

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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!

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: use WillPaintObserver

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 640931 [details] [diff] [review]
use WillPaintObserver

r=me, but it doesn't seem to help much on the actual testcase.  :(

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/23c13d1dd606

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/23c13d1dd606

Comment 10

[Konstantin Svist]

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.. :)

Comment 11

[Boris Zbarsky [:bzbarsky]]

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.  ;)

Comment 12

[The Veritable Bugeater]

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

Comment 13

[Konstantin Svist]

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

Comment 14

[Konstantin Svist]

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?

Comment 15

[Jacob Champlin]

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.

Comment 16

[Konstantin Svist]

Attachment: SickRage - The Daily Show.html.gz

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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.

Comment 18

[Konstantin Svist]

Attachment: 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?

Comment 19

[Konstantin Svist]

Attachment: performance profile (with OMTC)

Same page load, but with OMTC enabled

Comment 20

[Konstantin Svist]

Note: previous comment mentioned OMTC -- that refers to layers.acceleration.force-enabled=true