~Draft~ Working POC for an idea I had while pondering #325.
The idea is simple: pull total input yrange max and min from the m4 output since it's already computing the values per pixel window and we just need to do one more max min each step and then return the summary values with the output.
MAIN THINGS TO TEST:
[x] pop a chart on this branch and one that is based on master's code ideally on the same symbol with more then 2 years worth of 1m OHLC
[x] check if one feels faster then the other
[x] do the same with an added --profile 10 to the chart cmd and see if you notice any further difference and/or worse numbers from the actual profiler output
Notes:
[x] ~right now this seems to be most effective on long term crypto (1m) charts and slower (read not as fast) on 1s feeds (due to the large zeroed arrays allocated for trade rates / dark vlm?)~ now fixed via https://github.com/pikers/piker/pull/342/commits/c6205175435fd03c90de87801abf4021ef4c847a which means even zero-ed series are cached correctly and we get the same during-downsample-mxmn speedup effects 😎
obviously the mxmn summary valules are computed with a flow is not being downsampled so there's still room for improvement presuming using numba or a streaming algo (like demire see #325) would do better for zoomed in / source data graphics in view cases.
the whole .maxmin() callback flow i still find super confusing, mostly because we have fsps on subcharts which each have flows but which also are somewhat needlessly calling ChartPlotWidget.maxmin() for each overlayed flow in a PlotItem
ideally we can somehow simplify this whole ChartView._maxmin(), ._set_yrange(), Flow.maxmin() orchestration to be more "top level triggered" by whatever view is in use and then not have Qt signal callbacks firing all over the place? needs more thought and definitely a rework to make it more understandable (unfortunately this is growing pains of figuring out how to make Qt's signals wackiness fit with our async engine..)
[x] made a follow up issue to begin digging into solutions for this mess in #343
~Draft~ Working POC for an idea I had while pondering #325.
The idea is simple: pull total input yrange max and min from the m4 output since it's already computing the values per pixel window and we just need to do one more max min each step and then return the summary values with the output.
MAIN THINGS TO TEST:
--profile 10to thechartcmd and see if you notice any further difference and/or worse numbers from the actual profiler outputNotes:
numbaor a streaming algo (like demire see #325) would do better for zoomed in / source data graphics in view cases..maxmin()callback flow i still find super confusing, mostly because we have fsps on subcharts which each have flows but which also are somewhat needlessly callingChartPlotWidget.maxmin()for each overlayed flow in aPlotItemChartView._maxmin(),._set_yrange(),Flow.maxmin()orchestration to be more "top level triggered" by whatever view is in use and then not have Qt signal callbacks firing all over the place? needs more thought and definitely a rework to make it more understandable (unfortunately this is growing pains of figuring out how to make Qt's signals wackiness fit with our async engine..)