Skip to content

canonical way to handle rapidly updating data? #1238

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mg1075 opened this issue Dec 8, 2016 · 2 comments
Closed

canonical way to handle rapidly updating data? #1238

mg1075 opened this issue Dec 8, 2016 · 2 comments

Comments

@mg1075
Copy link

mg1075 commented Dec 8, 2016

I've tried to investigate some of the github issues and cannot find a definitive answer on the best way to handle data updates for a graph. (I could very well be missing an existing answer.)

  1. If high volume data is coming in at a rapid rate (i.e., worst case scenario), what is the recommended way to update the graph?

  2. Does the way you update a graph depend on the type of graph where the data is changing?
    Meaning, are certain update methods exclusive to certain graph types?

  3. Do certain graph types not have an update method, and you simply have to redraw the whole thing?

  4. Is there a good example of how a graph should be updated? (I am surprised there is not an example on the plot.ly site.)

@rldotai
Copy link

rldotai commented Jan 13, 2017

That's weird, I could have sworn there was an example somewhere under the Function Reference.

The thing to use is Plotly.extendTraces(gd, traces, indices, maxPoints).
Search through the code in the repository if you want a more detailed explanation, or check the information available from the community site

There are a few questions similar to yours on the community site

Here's a simple example

In my experience this seems to be the fastest way to add new data; depending on your use case you might want to use the GL versions of the various charts (e.g., 'scatterglinstead ofscatter`).
They mostly work well (except for a weird bug) and are substantially less resource intensive.

@etpinard
Copy link
Contributor

Closing. Work on #2358 will start in the coming days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants