Scattergl plot is sometimes slow to interact with even with moderate number of points #5927
Copy link
Copy link
Open
Labels
Description
With constant number of points and other settings, I see that Scattergl rendering times vary a lot. With 100,000 points, there are cases where it is virtually impossible to interact with the plot (e.g. zoom), and just moving the mouse seem to cause lengthy calculations.
For example, the following code from the doc works well:
import plotly.graph_objects as go
import numpy as np
N = 100000
fig = go.Figure(data=go.Scattergl(
x = np.random.randn(N),
y = np.random.randn(N),
mode='markers',
marker=dict(
color=np.random.randn(N),
colorscale='Viridis',
line_width=1
)
))
fig.show()
but if I replace the x data by zeros,
x = np.zeros(N),
performance is significantly degraded (so much that using Scatter instead of Scattergl becomes better when trying to zoom in a box).
Any ideas where the difference is coming from and how performance could be improved in this case?
Thanks.
Reactions are currently unavailable
Activity
bruot commentedon Sep 7, 2021
With this
xdata, things are equivalently slow:Related: #5881. But the problem is not limited to zeros.
CmpCtrl commentedon Sep 15, 2021
Just to add to this, the issue is related to the hover events and is sensitive to the distribution of the data. Randomly distributed data runs very quickly, but real world data tends to be extremely slow. Artificial data like the linear plot in the example below is also slow, as is random data that has an outlier like @bruot's example above.
I came across the issue using Dash, which is new to me, so please excuse my poor diagnostics. Hopefully this can help point someone in the right direction.
I made a sample python script to demonstrate the issue in Dash.
In the image below I used Chrome's performance profiling tool. The first 3seconds or so seconds was hovering around over the Random Data plot, that responds fine. Then at about 3s I moved the mouse to hover over the linear data plot where it appears to hang for about 6 seconds before the hover label appears, then around another full second before the hover label updates after a move.

It appears to spend most of its time in this L function in the minified async-plotlyjs.js

I think this is also related to #1698
Hopefully this helps someone who understands this a lot better than myself diagnose to the issue.
CmpCtrl commentedon Sep 15, 2021
Clearly I shouldn't rely on google to effectively search the issues list... #5790 is also related.
Entropy5 commentedon Feb 17, 2022
I have the same problem
250k points of my own dataset lags more than 1M random points from their example
jvdd commentedon Mar 2, 2022
It might be interesting to consider plotly-resampler when you want to visualize large datasets.
This extension adds resampling functionality to Plotly figures (by running an under the hood dash app), allowing to visualize tons of datapoints while being responsive.
siiruli commentedon Aug 29, 2023
I isolated the issue to commit 907415a, which changes the default value of
spikedistancefrom20to-1. This means there is now no cutoff for searching data for spikelines.Setting
spikedistance: 0fixed the problem for me. This is weird because my app was not drawing any spikelines, so it shouldn't need to calculate anything related to them. It looks like the code finds the points first and then filters out everything that doesn't allow spikelines.plotly.js/src/components/fx/hover.js
Lines 569 to 589 in a5577d9
Setting
hovermode: 'x'helped slightly but not enough, and disabling hovering also fixed the issue, but hoverlabels were necessary in my application.I'm pretty sure that issues #6792, #5881, #6054, and maybe #5790 are also caused by this. The change was added in plotly.js version v2.0.0-rc.2 and affects dash versions 1.21.0 and later.
CmpCtrl commentedon Aug 30, 2023
Cool, glad to hear about some progress on this issue. I haven't had a chance to work with it recently (and won't in the near term) but i'm excited to look into it further. Thanks.
CmpCtrl commentedon Jun 23, 2024
Another year later, and i'm surprised this isn't a bigger issue for more users. I took a quick look at issues and one more that i think is related is #6174.
@siiruli's find of the default spike distance seems to fix the issue for me. Setting the default back to 20pixels works great. Does anyone know why that shouldn't be reverted?
CmpCtrl commentedon Nov 22, 2024
@gvwilson Any updates on this? It seems like a straightforward fix to revert the
spikedistanceto 20 pixels. Is there a reason not to do that?A quick glance at more recent issues, it seems like #7065 may be related.
gvwilson commentedon Nov 22, 2024
HI @CmpCtrl - I'm sorry we haven't been able to get to it, but we're trying to wrap up the next major release of plotly.js (which I hope will be done next week, but I've been saying that for several weeks now). After that we have a handful of high-priority fixes for internal needs; I hope we can prioritize this once those are out of the way. Thanks - @gvwilson
Web:QC Page: Centralize setting 'chart_Layout.hovermode = false'