1349676 - Firefox hangs opening extremely large files on searchfox

Status: NEW

(Core :: Layout, defect, P3)

Description

[Jorg K (CEST = GMT+2)]

+++ This bug was initially created as a clone of Bug #1235321 +++

Firefox hangs opening
http://searchfox.org/comm-central/source/mozilla/db/sqlite3/src/sqlite3.c#39310

Using stock-standard FF 52 (x64) on Windows 10 x64.

I believe some work was done in bug 1235321, but it still hangs.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Funny enough, I was just profiling the same thing, but with http://searchfox.org/mozilla-central/source/testing/web-platform/meta/MANIFEST.json

Based on that profile, one issue is that all the <code> elements on this page (one per line) are floated left.  So we have a huge number (over 200,000 for both of those files) of floats in a row.

I'm seeing a rather large amount of time spent under BlockReflowInput::AddFloat, and in particular under nsFloatManager::GetFlowArea.  Almost all the time is actually self time _in_ GetFlowArea.  This function will in some cases have to walk the entire float list, which gives the whole thing O(N^2) behavior.  And N is about 2e5 in this case.

We could try to improve this, but I'm not sure it's better in any other browsers either, or how easy it would be to improve without breaking other things.

Bill, is there a reason all those <code>s are floated?

Comment 2

[Boris Zbarsky [:bzbarsky]]

In particular, if I just remove the "float: left" styles from the "td pre code" rule in mozsearch.css and replace them with "display: block", the rendering looks the same to me...

Comment 3

[Xidorn Quan [:xidorn] UTC+11]

(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #1)
> I'm seeing a rather large amount of time spent under
> BlockReflowInput::AddFloat, and in particular under
> nsFloatManager::GetFlowArea.  Almost all the time is actually self time _in_
> GetFlowArea.  This function will in some cases have to walk the entire float
> list, which gives the whole thing O(N^2) behavior.  And N is about 2e5 in
> this case.

This sounds very familiar to me... I recall bug 827937 comment 14. This might be actually a dup of that.

And using lots of floated element for source code viewing seems to be a very common practice which we definitely should optimize.

Comment 4

[Jorg K (CEST = GMT+2)]

Hmm, Chrome can't display the page either. At least it doesn't freeze other tabs, but that's most likely due to its multi-process support (which in my FF isn't enabled yet).

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

> Bill, is there a reason all those <code>s are floated?

I copied the code from DXR and I guess they did that at the time I copied it. I've been meaning to fix this for a while, but I want to do a little more testing to make sure there aren't any edge cases that break.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Filed bug 1350025 on the searchfox side of this.

Comment 7

[Jet Villegas (inactive)]

(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #1)
> This function will in some cases have to walk the entire float
> list, which gives the whole thing O(N^2) behavior.  And N is about 2e5 in
> this case.

I'm not sure how much we can speed this up (the thousands of CSS floats case) and have it be noticeable. I think this a site bug (per comment 4.)

Comment 8

[Naveed Ihsanullah [:naveed]]

Is this behavior unusual and particular to this site? If so I can mark as qf-

Comment 9

[Jet Villegas (inactive)]

(In reply to Naveed Ihsanullah [:naveed] from comment #8)
> Is this behavior unusual and particular to this site? If so I can mark as qf-

I haven't seen that elsewhere (e.g., https://cs.chromium.org uses display:block for line numbers.)