1349676 - Firefox hangs opening extremely large files on searchfox

Status: RESOLVED WORKSFORME

(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+10]

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

Comment 11

[Daniel Holbert [:dholbert]]

[--> adjusting URL to be a permalink, so it's more stable in the face of potential changes or directory-moving for the file in question]

I think this has gotten better (possibly due to changes on the searchfox side, not sure).

Today, Firefox/Gecko is the only engine that can even load this page. Specifically:

• Firefox 131.0a1 Nightly finishes loading this searchfox page in about 15 seconds on my machine (slow but tolerable).
• Chrome and WebKit (epiphany) never seem to finish loading it. Chrome eventually switches to a content-process-crashed page after maybe 90 seconds, whereas epiphany just repeatedly pops up "this page is not responding" notices for several minutes (at which point I gave up).

Given the substantially-worse outcomes in other browser engines as compared to us, it's not clear there's much more room for improvement when handling a page of this size/complexity.

(I was curious if we landed a fix that helped here, but I don't think so -- Nightly 48.0a1 2016-03-14 [from before this bug was filed] loads the page in roughly the same time as current Nightly.)

Comment 0 sounds like it was describing a literal hang, so from that perspective, I think we can consider this WORKSFORME since it doesn't hang in Firefox anymore; it just takes several ~tens of seconds (vs. hanging-or-crashing in other browsers).