Bug 19368 – Extremely slow parsing of deeply nested divs

• Component: DOM
• Status: RESOLVED CONFIGURATION CHANGED

[Michael A. Puls II]

WebKit-SVN-r34278 with Safari Win32 3.1.1(525.17)

Parsing ~15840 divs deep takes a long time in Webkit.

On a PIII 733MHz, Opera 9.5 (latest snapshot) and FF3 (latest trunk) take around 1.5 to 2 seconds to parse.  Webkit takes ~66 seconds.

Seems like there's room for optimization.

Will attach example.

[Michael A. Puls II]

Created attachment 21474 [details]
Example

(In reply to comment #0)
> On a PIII 733MHz, Opera 9.5 (latest snapshot) and FF3 (latest trunk) take
> around 1.5 to 2 seconds to parse.  Webkit takes ~66 seconds.

Opera 9.50 beta constructs a DOM tree only about 500 levels deep; Firefox 3.0b4 caps at around 200.

[Michael A. Puls II]

(In reply to comment #2)
> (In reply to comment #0)
> > On a PIII 733MHz, Opera 9.5 (latest snapshot) and FF3 (latest trunk) take
> > around 1.5 to 2 seconds to parse.  Webkit takes ~66 seconds.
> 
> Opera 9.50 beta constructs a DOM tree only about 500 levels deep; Firefox 3.0b4
> caps at around 200.

Confirmed and it seems Webkit caps at around 1024.

What's actually happening here? document.getElementsByTagName("div").length reports all 15840 divs.  Are they somehow flattened during parsing so they don't run so deep?

[Ahmad Saleem]

I think browsers in general are well-optimised and CPU architectures have evolved to an extent where these div cases does not lead to any crash or parsing time consumption.

In all browsers (Chrome Canary 106, Firefox Nightly 105 and Safari 15.6 on macOS 12.5 using M1 Pro), this test case load instantly and in Console using - document.getElementsByTagName("div").length, it shows 15840 for everyone.

[e-mail] & [e-mail] - Is there something needed here, or we can mark it as "RESOLVED CONFIGURATION CHANGED" or "RESOLVED WONTFIX"?

[Ryosuke Niwa]

This doesn't seem that slow to me now.