109885 - very slow loading Unicode page

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Markus Hübner]

Mozilal hangs on the page-load. No progress bar is being displayed.
usind build 2001111203 on win2k.
the page works fine in msie6.0 and opera6 beta1

Comment 1

[Markus Hübner]

btw: CPU usage is 100%

Comment 2

[Boris Zbarsky [:bzbarsky]]

Over to HTML tables.

There is no hang here.  There is just a table with 65500(!) or so rows.  It
takes a long time to render.  About 6 minutes on my machine (p3-733 with 640MB ram).

Reflow does not seem to be the culprit -- fixing the column widths is not making
this any faster.

A profile using jprof shows:

Count %Total  Function Name
3923   45.7     nsCSSFrameConstructor::FindFrameWithContent(nsIPresContext *,
nsIFrame *, nsIContent *, nsIContent *, nsFindFrameHint *)
615   7.2     nsGenericElement::GetBindingParent(nsIContent **)
445   5.2     nsRenderingContextGTK::GetTextDimensions(unsigned short *,
unsigned int, nsTextDimensions &, int *)

Over to style system to look at speeding up FindFrameWithContent...

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: jprof output

Comment 4

[Boris Zbarsky [:bzbarsky]]

um.  Ignore the "Over to HTML tables." part.  I forgot to delete it... :)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Looking at FindPrimaryFrameFor, it needs to do a linear search for frames that
are not in the hash table.  At the same time, we don't put row frames in the
hash table.

At a guess problem arises as follows:

SinkContext::CloseContainer()
SinkContext::DidAddContent()
SinkContext::FlushTags()
HTMLContentSink::NotifyAppend()
nsHTMLDocument::ContentAppended()
nsDocument::ContentAppended()
PresShell::ContentAppended()
PresShell::GetPrimaryFrameFor()

So for every table row we end up walking all the child frames of the table
looking for that row.  This makes loading tables O(n^2) in the number of rows.

Should we consider hashing table rows?

Comment 6

[Marc Attinasi]

There is this interesting comment in nsCSSFrameConstructor:

  // We want to be able to quickly map from a content object to its frame,
  // but we also want to keep the hash table small. Therefore, many frames
  // are not added to the hash table when they're first created:
  // - text frames
  // - inline frames (often things like FONT and B)
  // - BR frames
  // - internal table frames (row-group, row, cell, col-group, col)
  //

So, there was some reason not to do rows, but I cannot think of it. I think
containers in general should be mapped, but I don't know the history on that.
CC'ing karnaze in case he knows about the 'internal table frames'.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Looks like ContentAppended should not be calling GetPrimaryFrameFor to start
with.  Adding dependency on the bug that covers that.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Profile after the GPFF patch from bug 109428 applied

OK.  The fix for bug 109428 cut pageload time on this page by a factor of 4.

I've done a new profile; now the biggest culprit is GetTextDimensions at 20.6%
(used to be 5%).

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

How does this compare between platforms?  Does Tomi's patch to switch to Unix to
the new text measurement APIs (probably over a year bitrotted by now) help at
all?  I can't even find the bug it's on.

Comment 10

[Tomi Leppikangas]

Did you mean
http://bugzilla.mozilla.org/show_bug.cgi?id=36146 ?

Comment 11

[Markus Hübner]

any news on that one?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Just tested with the patch from bug 36146.  It helps a tiny bit; a lot less time
is spent in nsRenderingContextGTK::GetTextDimensions, but more time is spent in
nsFontMetricsGTK::LocateFont so overall it's about the same.

Comment 13

[Markus Hübner]

Testing with trunk build 2002072208 on win-xp pro,1.1ghz,512ram it takes 
15,382secs. [msie6 about 5 secs.]

Comment 14

[Boris Zbarsky [:bzbarsky]]

back to layout; if anything, this is tables but an up-to-date profile would be good.

Comment 15

[Bartosz Wucke]

Attachment: Testcase without tables

The file attached causes Mozilla to mostly freeze for some 20 seconds - it
contains just bare bones - head, body, one paragraph and br-separated Unicode
characters from #0 to #4095. It's 70K long, not much for a webpage and pages
way longer than this get rendered in a few seconds (a corresponding webpage
with & replaced with other character, breaking unicode display, renders below
1s).
Moreover, both MSIE, Opera and even Lynx render this kind of webpage within
seconds, while both Mozilla for Linux and Windows.

Note one thing more, the rendering time feels as it was growing exponentially
with character number. Similar file with 8192 characters caused Mozilla to
freeze completely, after some 8 minutes I lost patience and killed the process.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment 15 is about a totally separate issue.  Please file a bug with that
testcase on the "BiDi" component and cc me on it...

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: profile with current build

Comment 18

[Boris Zbarsky [:bzbarsky]]

With a realtime profile, almost all the time is spent in reflow (442576 of
515380 hits are spent under ProcessReflowCommands, with the bulk of the rest
under parsing and frame construction).

Of those 442576 hits, 298383 are under nsTextFrame::MeasureText; of thsoe
298383, 172004 are under gdk_font_load; most of these last (171793) are under
select(), called from _XRead, under XFreeFont.

So about a third of our time is spent waiting on X to respond (I wonder why we
go out to X so much here.....).  For the rest, it looks like we just
incrementally reflow every so often, which makes the load O(N) or O(N^2) in the
number of rows....

Comment 19

[Christopher Blizzard (:blizzard)]

That's not an xft build, right?

Comment 20

[Boris Zbarsky [:bzbarsky]]

No, it is not.

Comment 21

[Christopher Blizzard (:blizzard)]

What about the same profile done on a recent xft build?

Comment 22

[Boris Zbarsky [:bzbarsky]]

I don't have an xft build on hand and don't have the disk space to create one,
really.  Someone would need to build one with jprof and profile.

Comment 23

[Andrew Schultz]

Attachment: profile with CVS/xft/gtk2

I loaded the page three times... each time only took ~1 second.

Total hit count: 1647
Count %Total  Function Name
191   11.6     _dl_sysinfo_int80
 59   3.6     nsStyleContext::GetStyleData(nsStyleStructID)
 41   2.5     nsCellMap::GetDataAt(nsTableCellMap&, int, int, int)

Comment 24

[Boris Zbarsky [:bzbarsky]]

If it loads in ~1 second you are _so_ not having a problem with this bug... ;) 
Over here it takes about 50 seconds.

What's interesting is that the bug was reported on windows... we can't really
blame the non-xft gtk font impl there, but maybe the Windows equivalent has
issues too?

Comment 25

[Andrew Schultz]

hrmm.. on retesting and paying more attention, it takes ~7 seconds.  a nightly
build (not xft) takes ~10 seconds.  Athlons rock.  :)

It was a bit deceptive because the xft build does not update the display while
it's loading.  The cursor is the only indication the page is reloaded.  The
non-xft build does display while loading (trying several different character
encodings).

Comment 26

[Boris Zbarsky [:bzbarsky]]

Note that the times may also depend on the fonts installed on the system, their
ordering in the font search path, etc....

Comment 27

[Marco Castelluccio [:marco]]

This continues to be a problem with Firefox 7.

Comment 28

[Boris Zbarsky [:bzbarsky]]

For what it's worth, at this point on Mac I see this page take about 4s to load uncached; about 2s cached.

Of that 2s:

 40% is textrun construction when adding textframes to inline min width data (under
     reflow).  
  7% is bidi resolution
 25% is reflow (including some bidi reordering at 4%, text reflow at 5%, and all the other
     reflow accoutrements: block reflow states, html reflow states, overflow storage,
     etc).
 13% is frame construction
  4% is HTML parsing
  4% is unloading the previous page
  
Not sure what we can do about the textrun thing here, nor whether the numbers look the same on other platforms.

Comment 29

[Daniel Holbert [:dholbert]]

Per comment 24 and earlier, this bug was filed on this page taking many tens of seconds (or worse) to render. (50s in comment 24; 15,382s in comment 13).

These days (and even in comment 28) it only takes a couple seconds, and I don't see a substantial difference between us vs. Chromium, so I don't think there's much left to be done here.