[BUG] Layout engine much slower on Chrome

[philippjfr]

When working with complex layouts the layout engine sometimes takes a considerable time to rerender because it has to measure the size of various components. For a long time I thought this was a general issue with the layout engine but it was just pointed out to me that this is much worse in Chrome.

In the contrived example below we have a reasonably complex layout of rows and columns and keep appending new rows with some text and plots.

from bokeh.layouts import Row, Column, Spacer
from bokeh.models.widgets import Div, Slider, Button
from bokeh.plotting import figure
from bokeh.io import curdoc

title = Div(text='<h1>Page title</h1>')

header = Row(children=[title, Spacer(sizing_mode='stretch_width'),
                       Div(text="Some link")],
             height=60, sizing_mode="stretch_width")

main = Column(sizing_mode='stretch_width')

def on_click(event):
    p = figure(sizing_mode='stretch_width')
    p.line([1, 2, 3], [1, 2, 3])
    row = Row(children=[Div(text="Some text") for i in range(10)]+[p],
              sizing_mode='stretch_width')
    main.children.append(row)

widgets = [Slider(start=0, end=10, title='Slider %d' % i) for i in range(10)]
button = Button(label='Click me')
button.on_click(on_click)
widgets.append(button)

nav = Column(children=widgets, width=200)

layout = Column(children=[header, Row(children=[nav, main])])

curdoc().add_root(layout)

The layout engine struggles the more items you add with the button presses in Chrome, while in Firefox it hardly slows down. Here are flame graphs generated by recording the performance in the two browsers.

Chrome

Firefox

You will note that it takes <2 seconds in Firefox and ~5 in Chrome. I'm not sure if this is just a Chrome performance issue but it would at least be good to investigate why it's so much slower and if anything can be done to fix it.

Versions:

Bokeh 1.4.0
Chrome Version 78.0.3904.108 (Official Build) (64-bit)
Firefox 70.0.1 (64-bit)

[MarcSkovMadsen]

And I have a Panel App where this is an issue in practice.

[bryevdv]

@philippjfr Thanks for the detailed issue, cc @mattpap

As an immediate step it might be helpful to continue to characterize where this is a problem. I.e. Chrome on all platforms? or only OSX? Are other browsers on other platforms ok? Any difference between Chome versions? Basically just good to narrow the scope of where exactly this happens as much as possible.

[philippjfr]

Seeing the same thing on Linux, can try out Windows later on I hope.

[xavArtley]

Hello don't know if it helps but there it is performance on windows 10 chrome Version 78.0.3904.108 (Build officiel) (64 bits):

Same test on firefox 60.0.1 (64-bit):

Howver the difference seems mitigate when not using the debugger
I made a rough test on 20 clicks an looking the scroll bar updating. It took me 27 seconds on chrome vs 23 seconds on firefox

[MarcSkovMadsen]

Here is a real world example. The layout engine is slow in Firefox but incredible slow in Chrome.

It's running at https://awesome-panel.org

System Info

• Panel: 0.7.0
• Bokeh: 1.4.0
• Python: 3.7.4
• OS: Windows 8.1
• Browser: Chrome

Gallery Code

The code for selecting and showing the app in the gallery is basically

def view() -> Column:
    """The gallery view of awesome-panel.org"""
    app_selection = Select(name="Select app", options=list(APPS.keys()))

    @pn.depends(app_selection.param.value)
    def selected_app(value):
        return APPS[value]()

    return Column(
        Markdown(TEXT),
        app_selection,
        Spacer(height=50),
        selected_app,
        sizing_mode="stretch_both",
        name="Gallery",
    )

• The full file can be found here https://github.com/MarcSkovMadsen/awesome-panel/blob/master/src/pages/gallery.py
• the repo is here https://github.com/MarcSkovMadsen/awesome-panel. I've created a tagged release with the current state of the project. It's 'bokeh-issues-9515'.
• If it is easier you can just inspect the code and run the docker file here https://hub.docker.com/repository/docker/marcskovmadsen/awesome-panel. The currect version is tagged with version 131.

[MarcSkovMadsen]

And just for comparison. It's much faster in a Jupyter Notebook. But Firefox is significantly faster than Chrome.

Im running this notebook https://github.com/MarcSkovMadsen/awesome-panel/blob/master/app.ipynb

and have this log

$ jupyter notebook app.ipynb
[I 04:54:31.256 NotebookApp] Serving notebooks from local directory: C:\repos\private\awesome-panel
[I 04:54:31.256 NotebookApp] The Jupyter Notebook is running at:
[I 04:54:31.257 NotebookApp] http://localhost:8888/?token=5f809af8188893692b9f863c8db8159841e4768130891117
[I 04:54:31.257 NotebookApp]  or http://127.0.0.1:8888/?token=5f809af8188893692b9f863c8db8159841e4768130891117
[I 04:54:31.257 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 04:54:31.891 NotebookApp]

    To access the notebook, open this file in a browser:
        file:///C:/Users/masma/AppData/Roaming/jupyter/runtime/nbserver-7816-open.html
    Or copy and paste one of these URLs:
        http://localhost:8888/?token=5f809af8188893692b9f863c8db8159841e4768130891117
     or http://127.0.0.1:8888/?token=5f809af8188893692b9f863c8db8159841e4768130891117
[I 04:54:36.293 NotebookApp] Kernel started: 0b477488-b6e8-433c-be95-42b46e49a125
[W 04:54:41.925 NotebookApp] 404 GET /api/kernels/6ed7af11-6e24-4a43-9c3f-b873b8db42db/channels?session_id=5ac847a8828f46bc8e3e2b7fa8e5955f (::1): Kernel does not exist: 6ed7af11-6e24-4a43-9c3f-b873b8db42db
[W 04:54:41.939 NotebookApp] 404 GET /api/kernels/6ed7af11-6e24-4a43-9c3f-b873b8db42db/channels?session_id=5ac847a8828f46bc8e3e2b7fa8e5955f (::1) 16.01ms referer=None
[I 04:54:46.510 NotebookApp] 302 GET /?token=5f809af8188893692b9f863c8db8159841e4768130891117[I%2004:54:31.257%20NotebookApp]%20Use%20Control-C%20to%20stop%20this%20server%20and%20shut%20down%20all%20kernels%20(twice%20to%20skip%20confir (127.0.0.1) 2.00ms
[I 04:54:46.584 NotebookApp] Saving file at /app.ipynb
[W 04:55:14.917 NotebookApp] Replacing stale connection: 6ed7af11-6e24-4a43-9c3f-b873b8db42db:5ac847a8828f46bc8e3e2b7fa8e5955f
[I 04:55:41.064 NotebookApp] Starting buffering for 0b477488-b6e8-433c-be95-42b46e49a125:fc57efbb9e6b40c3ab18bb4aec6e49f4
[I 04:55:42.401 NotebookApp] Kernel shutdown: 0b477488-b6e8-433c-be95-42b46e49a125
[I 04:55:45.803 NotebookApp] Kernel started: 4c1f0636-7239-43ae-b32b-d7c6a6b7fd19
[I 04:57:46.056 NotebookApp] Saving file at /app.ipynb
[W 05:00:19.905 NotebookApp] Replacing stale connection: 6ed7af11-6e24-4a43-9c3f-b873b8db42db:5ac847a8828f46bc8e3e2b7fa8e5955f

and this error message

Javascript error adding output!
Error: Mismatched anonymous define() module: function(){return function(){return function t(e,r,n){function a(o,s){if(!r[o]){if(!e[o]){var l="function"==typeof require&&require;if(!s&&l)return l(o,!0);if(i)return i(o,!0);var c=new Error("Cannot find module '"+o+"'");throw c.code="MODULE_NOT_FOUND",c}var u=r[o]={exports:{}};e[o][0].call(u.exports,function(t){return a(e[o][1][t]||t)},u,u.exports,t,e,r,n)}return r[o].exports}for(var i="function"==typeof require&&require,o=0;o<n.length;o++)a(n[o]);return a}}()({1:[function(t,e,r){"use strict";var n=t("../src/lib"),a={"X,X div":"direction:ltr;font-family:'Open Sans', verdana, arial, sans-serif;margin:0;padding:0;","X input,X button":"font-family:'Open Sans', verdana, arial, sans-serif;","X input:focus,X button:focus":"outline:none;","X a":"text-decoration:none;","X a:hover":"text-decoration:none;","X .crisp":"shape-rendering:crispEdges;","X .user-select-none":"-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;-o-user-select:none;user-select:none;","X svg":"overflow:hidden;","X svg a":"fill:#447adb;","X svg a:hover":"fill:#3c6dc5;","X .main-svg":"position:absolute;top:0;left:0;pointer-events:none;","X .main-svg .draglayer":"pointer-events:all;","X
....
....
....

[bryevdv]

OK For me (and probably @mattpap) to look into this we really need a pure Bokeh reproducer. I've tried to approximate the structure of this how I would in Bokeh. Does this run OK for you? (It does for me on Chrome and Safari) If so, what to do we need to do to it it get it closer to what Panel does? @philippjfr

"""## The Gallery Page of awesome-panel.org"""
from bokeh.io import curdoc
from bokeh.layouts import *
from bokeh.models import *

TEXT = "Some Header Text"

info = column(Div(text="Info"), sizing_mode="stretch_width")
bootdash = column(Div(text="Bootstrap Dashboard"), sizing_mode="stretch_width")
df = column(Div(text="DataFrame"), sizing_mode="stretch_width")

APPS = {"Info Alert": info, "Bootstrap Dashboard": bootdash, "DataFrame": df}

app_selection = Select(name="Select app", options=list(APPS.keys()), width=100)

layout = column(
    Div(text=TEXT),
    row(app_selection),
    info,
    sizing_mode="stretch_both",
)

def selected_app(attr, old, new):
       layout.children[2] = APPS[new]

app_selection.on_change('value', selected_app)

curdoc().add_root(layout)

[MarcSkovMadsen]

I guess the problem is not so much there for the simple example. The trouble starts when you have an advanced layout with columns and rows inside of each other that are full width, responsive.

If I run the simple Panel version of your code as below the speed is acceptable although not impressive.

"""## The Gallery Page of awesome-panel.org"""
from panel import Column, depends, Spacer
from panel.widgets import Select
import panel as pn

from awesome_panel.express._pane._panes import Markdown
from awesome_panel.express.bootstrap import InfoAlert
from gallery.bootstrap_dashboard import components, app

TEXT = """\
# Awesome Panel Gallery ![Awesome Badge](https://cdn.rawgit.com/sindresorhus/awesome/d7305f38d29fed78fa85652e3a63e154dd8e8829/media/badge.svg)

I hope this gallery can show case the power of Panel and inspire you as you build awesome analytics apps in Panel.

If you have an awesome tool or app you wan't to show case here you are very welcome.
You can do so via a [pull request](https://github.com/MarcSkovMadsen/awesome-panel/pulls)."""

INFO_TEXT = """\
Please **use FireFox, Safari or Edge** if you can.

Alternatively you can use Chrome - but it's
[slower](https://github.com/bokeh/bokeh/issues/9515).

This page does not render nicely in Internet Explorer and it's not supported.

Please **have patience** as some of the apps can take 10-30 seconds to load.
"""


def info():
    return Column(InfoAlert(text=INFO_TEXT), sizing_mode="stretch_width")


APPS = {"Info Alert": info, "Bootstrap Dashboard": app.main, "DataFrame": components.dataframe_view}


def view() -> Column:
    """The gallery view of awesome-panel.org"""
    app_selection = Select(name="Select app", options=list(APPS.keys()))

    @pn.depends(app_selection.param.value)
    def selected_app(value):
        return APPS[value]()

    return Column(
        Markdown(TEXT),
        app_selection,
        Spacer(height=50),
        selected_app,
        sizing_mode="stretch_both",
        name="Gallery",
    )


view().servable()

[mattpap]

The layout engine struggles the more items you add with the button presses in Chrome, while in Firefox it hardly slows down.

I can't reproduce this. For me both are slow beyond being usable (after maybe 8-10 clicks). By the nature of things, layout should struggle more when more items are added, and by design it should struggle significantly more when more free form HTML items are added, which is the case here.

Bokeh's layout was designed as a fully managed layout, i.e. all layout computations are done in a JavaScript runtime and don't fundamentally require a CSS engine. We obviously have to interact to some extent with the CSS engine of a web browser to get real measurements (fonts, images, free form HTML, etc.). However, we don't have to or we can choose how much we depend on it. This way layout can work within HTML canvas, as well as (potentially) in environments where there is no DOM (and CSS) access at all (e.g. web workers, WASM), or even outside a web browser (e.g. node with node-canvas).

The side effect of this design is that mixing bokeh's layout with free form HTML is expensive. This is because the layout has to measure HTML fragments in various configurations and then remeasure when adjustments are needed. Each measurement results in a CSS reflow (layout), which is expensive on its own. If you add this up over dozens or hundreds of layout items, then you have performance characteristic as showed in this issue.

Having a big performance difference between FF and Chrome is unexpected. Maybe FF's CSS engine got suddenly better or Chrome has had a recent regression. Maybe there are platform specific differences that affect this. For long running tasks GC may be skewing the results. Long tasks should be manually split to give GC a breather (we already do this during initialization, because otherwise bokehjs would stall on large object graphs). Or the testing methodology is flawed in general (see below).

I suppose that layout could be improved in its current form, but ultimately we will need to look into different designs that would cooperate with CSS layout, instead of fighting against it.

However the difference seems mitigate when not using the debugger (...)

This may be the case as well. Performance analysis in web browsers is a tricky business and comparison of bare numbers between browsers should be done with care.

[philippjfr]

Thanks for the detailed answer @mattpap. I understand that there are a lot of constraints on the layout engine and that measuring the size of contents is needed. I think investigating why Chrome is one approach we could pursue but I suspect that may just be a fundamental limitation or indeed some problem in my testing approach.

My other question then is whether we could help the layout engine out in some way, currently any modification to a layout triggers re-measurement of all the components which is obviously very expensive. Is there any chance that components could cache their sizes so that it doesn't have to re-measure all the time. I realize this is tricky because you have to make very sure that if the component is responsive, or the contents or some layout property changes the cache would have to be invalidated but I still think this might be worth investigating. Even manually declaring some part of the layout as fixed after the initial measurement might be sufficient. Let me know if you think if that's even worth investigating or if there are some fundamental reasons this can't work.

[philippjfr]

@mattpap I've been digging into the measurement code a bit to try to figure out if there are any easy gains to be made and I noticed something strange, it seems that for each call to Layoutable.measure the Layoutable._measure call is run exactly 4 times. In every scenario I've seen so far each of those calls returns exactly the same width and height values which makes it seem quite redundant.

Is this on purpose? I can't really see where that happens in the code but if I cache the Sizable on the Layoutable on the first call to Layoutable._measure and return that on the subsequent three calls everything stays highly responsive and as far as I can tell the layout is no different. That said you clearly do have to invalidate the cache in certain cases, e.g. when the viewport size changes. It's not even just a 4x speedup, it's in excess of 10x (maybe because of GC).

[philippjfr]

Actually a slight addendum to my comment above, the number of times Layoutable.measure will call Layoutable._measure depends on the complexity of the layout, here's what it looks like for the example I posted above:

The 10x speedup in this case is therefore not too surprising.