@carl Thanks for input. Seems to me the issue/bug 5546 on GitHub could be relevant, although the behavior he’s showing in the videos is different.
Regarding the idea of “too many data points”, I agree that shouldn’t be the case. My entire code works great with if you use the “generic” data option. Much more data than the “real data” option.
I have also tried the “only plot a subset and repeat with more until it breaks” approach. The easy method for this is to slice the following:
for top_key, curves in list(curves_dict.items())]
becomes something like:
for top_key, curves in list(curves_dict.items())[:8]]
Interestingly, playing around with my MRE, it seems like it’s handling more real data set today than my prior troubleshooting. Today slicing just the first 8 parameters was the lowest number to show performance issues. Slicing to 9 (all of the parameters) makes it grind to a halt. Last week plotting only 5 or 6 made it grind to a halt.
Also note that removing the datashader function, plotting the entire real dataset works fine, where instead of:
self.overlay = [datashade(hv.NdOverlay(curves), line_width=line_width, pixel_ratio=pixel_ratio,
cnorm=cnorm, aggregator=ds.count()
).opts(width=plot_width, tools=['hover']).relabel(top_key)
for top_key, curves in list(curves_dict.items())[:9]]
becomes:
self.overlay = [(hv.NdOverlay(curves)).opts(width=plot_width, tools=['hover']).relabel(top_key)
for top_key, curves in list(curves_dict.items())[:9]]
… and that is fine for small datasets, but i’m looking for a solution that can plot millions of data points, and so the datashader operation will be necessary. Fortunately, we can recreate the issue with the small “real” dataset.
One theory of mine is that hv/ds don’t like either:
- The time-series index of these “real” signals are ascynchronous between eachother, while the “generic” are synchronous.
- Or the fact that some of these data sets have a large time gap in the middle of them. Perhaps hv/ds have to work extra-hard to deal with the space between?