Hold streams together for faster plot callbacks

[ahuang11]

Philipp suggested this; not sure if the following is necessary:

                if self.plot.comm:
                    push_on_root(self.plot.root.ref['id'])

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.47%. Comparing base (2ba3d78) to head (1afb3a8).
Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6247      +/-   ##
==========================================
+ Coverage   88.39%   88.47%   +0.08%     
==========================================
  Files         323      323              
  Lines       67620    67642      +22     
==========================================
+ Hits        59770    59849      +79     
+ Misses       7850     7793      -57     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ahuang11]

I tried this too, but I'm not sure why self.plot.root is a Row instead of a bokeh figure

            with self.plot.root.hold_render():
                with set_curdoc(self.plot.document):
                    Stream.trigger(streams)

[philippjfr]

but I'm not sure why self.plot.root is a Row instead of a bokeh figure

The root is the Bokeh root on the Bokeh document and will change depending on whether you are rendering the plot on its own or inside some Panel component.

[philippjfr]

I'd suggest using:

            with self.plot.state.hold_render():

[philippjfr]

@ahuang11 Can you confirm whether this still gives the expected speedups?

[ahuang11]

It seems so.

This is self.plot.state.hold_render(B)

b.mp4

And this is self.plot.document.hold() (A, original)

a.mp4

hold_render (B) seems to do it in batches, and potentially seem a little faster because upon wheel zoom, it throttles vs non-throttle. I do like how (A) updates each line individually for a sense of progress.

[ahuang11]

Seems like it works in notebook (VSCode)

c.mp4

[philippjfr]

That looks much slower than what we saw originally, no?

[ahuang11]

We previewed it on @droumis 's machine last time. Also, not sure if he used the same resampled data tree as me.

A is the "original" method.

[droumis]

Seeing 2:4 second lag on my end for render updates for this self.plot.state.hold_render approach. I'm also including in here Philipp's fix to the rangetoolink to work with subcoordinate_y.

I'm not seeing the blanking when box-zooming, but I'm also not subselecting channels based on the viewport, just time slicing. Andrew, can you show me your channel-slicing approach? Here's the version of the code I used for this.

video2300728378.mp4

What was the code block we initially saw very good speed with? I'll try that again too

[droumis]

What was the code block we initially saw very good speed with? I'll try that again too

Assuming the 'original' code block was the following

                self.plot.document.hold()
                try:
                    Stream.trigger(streams)
                finally:
                    self.plot.document.unhold()

With the original approach, I'm seeing slightly faster times, ~1-3 seconds for updates (also, still not channel slicing):

video2602508095.mp4

[philippjfr]

Someone should dig into this with the browser performance profiler like we did last time to see what it's doing while you wait for the update.

[ahuang11]

I'd define channel_slice like this:

    channel_slice = slice(y_range[0], y_range[1])

    # calculate the appropriate pyramid level and


    ...
    # extract new data and re-paint the plot
    ds = _extract_ds(ts_dt, pyramid_level, channels).sel(time=time_slice, channel=channel_slice).load()

    ...
    for channel in ds["channel"].values.tolist():

[droumis]

Ok, I've added the channel slicing. The performance is better now all around, even without holding the render. But now I'm seeing a lot of fragility with the channel y-ticks while navigating around.. e.g.:

@ahuang11 , do you see this as well? Is it the same thing as mentioned here?

[droumis]

Initial Profiling:

Baseline (with channel slicing, no render holding):

baseline_no-hold.mp4

plot.document.hold

plot.document.hold.mp4

plot.state.hold_render

Sometimes can take very long to update, other times very quick

plot.state.hold_render.mp4

[ahuang11]

@ahuang11 , do you see this as well? Is it the same thing as mentioned #6256 (comment)?

Yes that's the same issue.

Thanks for doing the profiling!

[philippjfr]

Closing in favor of #6265

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.