7455 - [dogfood]{perf} large <pre> sections take forever to render

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Tomi Leppikangas]

Large (~1MB) files with long <pre> sections take forever to render.

Above url has our server stat pages, they are about 1-2mb size, beging
of page gets loaded properly, tail of page have large <pre> section and
it hangs viewer.

Comment 1

[rickg]

Most likely a large document bug

Comment 2

[Hixie (not reading bugmail)]

Marking M15. This is an incremental reflow bug. PRE sections are not reflowing
incrementally -- it appears that the entire <PRE> element must be downloaded
before it displays.

Comment 3

[kipp]

Changed {} marker to performance...

Comment 4

[Tomi Leppikangas]

Now this is even worse, sample url doesnt show anything, apprunner just
hangs doing layout.  Just for status update.

Comment 5

[kipp]

Added dogfood tag for pdt checking

Comment 6

[kipp]

Linking this to bugs that all involve work in the text-transformer logic.

Comment 7

[kipp]

Some data: (1) the text-transformer logic wasn't handling pre sections
particularly efficiently (each space is returned independenty). I have fixes for
this in my tree. But... (2) the real problem is the text measuring logic in
nsRenderingContextGTK.cpp -- massively slow logic.

Comment 8

[Tomi Leppikangas]

Looks like kipp is right, xlib versions renders long pages much faster,
my sample stats page renders in 71sec, gtk-verion takes minutes, more like
10min.

Maybe someone should steal xlib's nsRenderingContextGTK::GetWidths to gtk?
Actually xlib code looks much same.. Some profile data would help.

Comment 9

[kipp]

Thanks for the update message; I'm wishing I had gprof that worked with shared
libs so I could *really* figure out where the time is spent...sigh.

Comment 10

[kipp]

Partially fixed today (as if this log message). I found two smoking guns:

(1) the block code has some O(N^2) debug logic (only affects debug builds of
course)

(2) the paint logic in the block code was out of date - it wasn't using the
combined area of each line to limit which lines to render *in certain cases*.

(3) the way that the nsTextTransfomer and the nsTextFrame worked together for
handling spaces was very stoopid. I've fixed both of them to be much more
efficient.

I'm leaving the bug open until after the content sink work lands

Comment 11

[kipp]

Attachment: a simple pre speed test that I've been using

Comment 12

[daver]

Seems like important performance work but not Dogfood.

Comment 13

[Tomi Leppikangas]

Nice work kipp! Now this is much better, page that takes +10minutes yesterday
takes now 40sec.

Comment 14

[kipp]

Fixed. It may require the landing of the content-sink work done by vidur (I'm
running with his changes in my tree to help test it) to see the full effects.
The linux specific issues included fixing the event queue to work like it does
on windows and to reprioritize the plevent queue to be lower than the ui events.
The sum of all this work is that the large document test cases all display the
first screenful quite quickly and the scrollbar is usable during loading :-)

Comment 15

[Chris Petersen]

Fixed in the Oct 22 Linux build.

Comment 16

[Chris Petersen]

Fixed in the Oct 22 Linux build.