Performance of layout engine

I am developing since a couple of days complex/multi-tabbed
layouts in Panel. I am trying to get my head around what is
actually happening in terms of re-drawing.

I observed that about 90 % of the time is spent outside
of my own event-handlers (they perform Pandas data wrangling etc.),
but simply re-drawing the layout.

I observed that the closer to the document root one changes
the layout the more drastic the performance slow-down is . Say
we have a top-level Tab layout and we dynamically add new tabs
in response to user actions. In my tests this could lead to
mis-render or even crash of the dashboard.

I understand from reading a Github issue on Bokeh that this slowness
is caused by recomputation of widget sizes. Will this be fixed in Bokeh 3.0
and when will this propagate to Panel?

1 Like

My current work-around is to keep the layout more
or less static close to the document root, and only replace widgets with
no children, such as leaf-level plots or not replace objects
but only over-writing param.values of widgets.

1 Like

This will be solved with bokeh 3.0, and it is being translated to panel in this pr


Ok, that’s great to hear. When is this release planned to happen? I think Bokeh 3 is released
on 24th October.

There’s nothing really complex about my app data-wise, except
the .options argument of MultiSelect widget can be quite large. Could
this be an issue in terms of rendering?

Yes Bokeh 3 should be released shortly. It is major release that comes with breaking changes and even if the Panel maintainers have anticipated that (testing out dev releases of Bokeh 3 and providing feedback) there will still be quite some work to do before being able to release a version of Panel that depends on Bokeh 3.

In the mean time it’d be great if you could provide the code of a small app that reproduces the performance impacts you’re observing.