Bug 226764 – Complex flex layout is very slow to load

• Status: NEW
• Component: Layout and Rendering

[Paul Guz]

Our dashboards are built using 'splitter' components that use flex.  A splitter may be either in a horizontal (flex:row) or vertical (flex:column) orientation.  Splitters are nested, potentially deeply, to divide up the dashboard.

We have found complex dashboards extremely slow to load on iPads.  Testing on Safari on an iPad Air 2 (MGLW2ZP/A) running iPadOS 14.6, the following fiddle takes 35 seconds to load. http://bitly.ws/e45Y

Compare with the following fiddle, with flex removed: http://bitly.ws/e45Y

The same is observed in Chrome on the same iPad.

Desktop browsers and Android tablets of a similar specification do not exhibit this slow performance.

I do not have easy access to MacOS or Linux at this time so cannot compare with desktop WebKit, nor can I test on Technology Preview.

A similar bug (https://bugs.webkit.org/show_bug.cgi?id=222202) was recently fixed, and I believe that fix would have been shipped with iPadOS 14.5.  Similarly to this bug, we use % widths.  However, unlike the test attached to that bug, we nest both column and row layouts.

[Paul Guz]

Sorry, the fiddle without flex is http://bitly.ws/e47x

[Sergio Villar Senin]

(In reply to Paul Guz from comment #0)
> Our dashboards are built using 'splitter' components that use flex.  A
> splitter may be either in a horizontal (flex:row) or vertical (flex:column)
> orientation.  Splitters are nested, potentially deeply, to divide up the
> dashboard.
> 
> We have found complex dashboards extremely slow to load on iPads.  Testing
> on Safari on an iPad Air 2 (MGLW2ZP/A) running iPadOS 14.6, the following
> fiddle takes 35 seconds to load. http://bitly.ws/e45Y

It isn't definitely fast on desktop (seems to take 2-3 seconds) but far from the 35 seconds you report on iOS.

> Compare with the following fiddle, with flex removed: http://bitly.ws/e45Y
> 
> The same is observed in Chrome on the same iPad.

I believe chrome on iOS uses WebKit so it's normal that you see the same behaviour

> Desktop browsers and Android tablets of a similar specification do not
> exhibit this slow performance.
> 
> I do not have easy access to MacOS or Linux at this time so cannot compare
> with desktop WebKit, nor can I test on Technology Preview.
> 
> A similar bug (https://bugs.webkit.org/show_bug.cgi?id=222202) was recently
> fixed, and I believe that fix would have been shipped with iPadOS 14.5. 
> Similarly to this bug, we use % widths.  However, unlike the test attached
> to that bug, we nest both column and row layouts.

Unfortunately I cannot know whether that patch was included in that release, not sure if anyone from Apple can comment on that. If the patch is not in that release then it might be very well the culprit (note that we observed a 4000% improvement after the patch is some benchmarks)

I understand the best test case you have is http://bitly.ws/e45Y. Could you try to clean it up a bit (removing all unneeded information) so that we could check what is causing that slow performance?

[Paul Guz]

Thanks Sergio.

I've removed all the extraneous comment characters, but the remainder is mostly necessary elements and their associated ids, classes and styles.  Some ids could be removed I suppose, but it would take some time and I don't have much more time to devote to this issue.

Here is the slightly cleaned fiddle: http://bitly.ws/e62p

[Alexey Proskuryakov]

The fix for bug 222202 should have shipped in 14.5, yes. I didn't verify source code, but bug trail says so.

[Radar WebKit Bug Importer]

<rdar://problem/79334032>

On the latest safari technology preview (127), the fiddle takes nearly 20 seconds to load on my 2017 15" Macbook pro. I would assume this STP version will have the fix for https://bugs.webkit.org/show_bug.cgi?id=222202 ?

Default safari (14.1.1 on my machine) is about the same speed.

We are seeing similar load times on some of our flexbox heavy pages, but unfortunately don't have a cleanly extracted test case yet. STP is better for our problem, taking around 8 seconds to render versus nearly 60 for Safari 14.1.1. When benchmarking it appears all the time is spent in layout , basically we put a timer around something like console.log(foo.offsetHeight); which triggers layout, and we are blocked for nearly a minute on Safari 14.1.1. We have an insanely large DOM, but Chrome and Firefox are handling this particular case without a problem.

[Simon Fraser (smfr)]

Lots of time under WebCore::RenderFlexibleBox::layoutFlexItems(bool). Looks like this is still O(N^2).