You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was looking for ways to improve the performance of the slicer, and decided to do a bit of benchmarking. This adds a script to test the performance of updating an image with Plotly+Dash.
It contains a dcc.Interval that tries to update a figure as fast as it can. The time it costs to do this will slow the interval down, so we can measure fps. Of course this FPS value depends on a lot of factors, but it's valuable to see the differences between methods.
Some observations:
Even if the (client-side) callback yields no_update, the FPS does not go beyond 20. Not sure whether this is some rate limit or some overhead in Dash.
When the callback returns an empty figure, the FPS is the same as doing noting, so that's good.
Heatmap is slow! (about 6-7 FPS for me).
The gl heatmap is only a wee bit faster (8 FPS). This makes no sense to me ...
The PNG approach (which we now use) is actually pretty fast! (13-14 FPS). It actually looks a lot faster than what I experience with the slicer, so we might gain performance by having a good look at the slicer internals.
The PNG approach that does not swap the y-axis grinds to a mere 6 FPS. I'd love to get this fixed ...
In summary, I had hoped the glheatmap would allow us to get more smooth interaction. Alas. On the plus side, we seem to have some internal overhead that we can hopefully fix to make things more smooth!
A question about serialization: did you compute the JSON serialization time of the figure? If it's a significant fraction of the time it might explain why the difference between heatmap and heatmapgl is not huge. (and are you using plotly 4.13 which should reduce the serialization time for Heatmap and Heatmapgl ?)
Update: forget what I wrote, since the callback is clientside probably there is no serialization
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I was looking for ways to improve the performance of the slicer, and decided to do a bit of benchmarking. This adds a script to test the performance of updating an image with Plotly+Dash.
It contains a
dcc.Intervalthat tries to update a figure as fast as it can. The time it costs to do this will slow the interval down, so we can measure fps. Of course this FPS value depends on a lot of factors, but it's valuable to see the differences between methods.Some observations:
no_update, the FPS does not go beyond 20. Not sure whether this is some rate limit or some overhead in Dash.In summary, I had hoped the glheatmap would allow us to get more smooth interaction. Alas. On the plus side, we seem to have some internal overhead that we can hopefully fix to make things more smooth!