116437 - Gzipped unihan data file seems to hang

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Justin Kerk]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6+) Gecko/20011214
BuildID:    2001121403

The URL http://www.unicode.org/Public/BETA/Unicode3.2/Unihan-3.2.0d2.txt.gz
seems to hang the browser--it may load something if you wait long enough (I
haven't tried), but you don't get any progress meter and you can't interact with
Mozilla at all.

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.unicode.org/Public/BETA/Unicode3.2/Unihan-3.2.0d2.txt.gz


Actual Results:  Browser freezes up; doesn't respond to input.

Expected Results:  Page rendered.

Comment 1

[Justin Kerk]

It seems the browser isn't completely hung - I was able to switch between 
tabbed windows, albeit painfully slowly. And Windows is very slow too, until 
you kill Mozilla with Ctrl-Alt-Del.

I tried opening the page with IE5 - it starts to render the page, then hangs.

I'm using a Celeron 466, BTW.

Comment 2

[Asa Dotzler [:asa]]

->file handling

Comment 3

[basic]

is this even a gzip problem? That file is huge. It takes me about 20 minutes to
download it on a dialup. When uncompressed that file takes up 24MB!! Mozilla
doesn't handle huge files well (nor do any other browsers I know of).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: jprof profile of loading this page

Comment 5

[Boris Zbarsky [:bzbarsky]]

Over to layout.  Looks like the usual problem, layout on large pages takes a
long time and starves the UI.  Nothing jumps out at me from the profile...

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Typical: 
  Mostly Reflowing lines:

12% direct (90% total) in ReflowDirtyLines()
4% total in nsFontCache::GetMetricsFor()
6% direct in nsBlockReflowState::RecoverStateFrom()
2% direct in nsBlockFrame::PropagateFloaterDamage()
3% total in nsFrame::Invalidate()
10% direct in nsLineBox::GetCombinedArea()
4% direct, 13% total in nsBlockFrame::ComputeFinalSize()
6% direct in nsBlockFrame::BuildFloaterList()
8% total in nsBlockFrame::PlaceLine()
1.5% total in nsCSSRendering::FindBackground
3% total in nsHTMLReflowState::nsHTMLReflowState
5% direct in nsFrameList::LastChild
10% total in nsRenderingContextGTK::GetTextDimensions()

I agree, this is just the "monster file makes mozilla seem to stop" bug. 
Probably should be duped with my comments above moved over and a pointer to the
jprof.

Comment 7

[Boris Zbarsky [:bzbarsky]]

This looks like a duplicate of bug 78911 to me. see other dependencies of bug
56854 as well....

Comment 8

[rubydoo123]

setting a dependency in 56854, and reassigning this to waterson -- Chris I am 
not really sure who this should go to, but I do know you  have been doing the 
perf thing

Comment 9

[Daniel Holbert [:dholbert]]

The testcase, http://www.unicode.org/Public/BETA/Unicode3.2/Unihan-3.2.0d2.txt.gz , seems to now be 404 "Not found", and I can't find a publicly-hosted version of this file, when searching Google for the filename.

So: this bug report is "incomplete" at this point. If anyone has a copy of this file and can still reproduce performance issues will it, please reopen. Thanks!

Comment 10

[Daniel Holbert [:dholbert]]

Ah, looks like we have a publicly-hosted version of probably-close-to-the-same-file here:
https://www.unicode.org/Public/3.2-Update/Unihan-3.2.0.txt.gz

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: Unihan-3.2.0.txt.gz

Here's a local copy of that Unihan-3.2.0.txt.gz file, for archival purposes.

Comment 12

[Daniel Holbert [:dholbert]]

Here's a profile of me loading the page in current Nightly (fresh profile):
https://share.firefox.dev/3vUineb

We finish loading in under 6 seconds. The profile shows about a 3-second period of jank (all spent in reflow), and then we paint, and then another 2.4-second jank, and then we're done.

For comparison, Chrome does its first paint after 1-2 seconds (slightly sooner) but it seems to never finish layout. Here's a profile taken in Chrome for 90 seconds:
https://share.firefox.dev/3pKkeRM

It shows repeated 1-2sec bursts of layout work, continuing forever. Chrome's pageload-throbber never stops spinning, and eventually the process dies and the tab goes to an error page with Error code: SIGILL. (I stopped profiling before that happened.)

So it looks like this is WORKSFORME -- loading in 6 seconds isn't great but it's much better than the behavior described in comment 0, and much better than the competition.