Faster y-range sorting - Githubissues

After #302 lands there are 2 main sources of latency left in chart interaction:

redraw latency (a much larger task to deal with that will require further extensions to our Rendering sub-systems) that contains:
- maybe a downsampling of data via m4
- a delete and redraw of a QPainterPath for the data in view
max() / min() sorting of the y-data in-view
- currently we naively use np.max()/.min() and very basic x-range caching inside our Flow type
- the display loop will also naively call this same method on updates, which if there's conditions to actually redraw a large (1M datums +) entire graphic in view, can be quite slow

In order to see this latency in action pass a --profile 10 to your piker chart command to see something like:

 > Entering `ChartView._set_yrange()`: `dolla_vlm`
    callback ._maxmin(): (0, 22800345.0): 24.8241 ms
    set limits: (-1368020.7, 24168365.7): 0.1694 ms
  < Exiting `ChartView._set_yrange()`: `dolla_vlm`, total time: 24.9964 ms
    > Entering `<piker.ui._chart.ChartPlotWidget object at 0x7f8b66fcae60>.maxmin(name=trade_rate)`: `volume`
      volume got bars range: 0.0380 ms
      yrange mxmn: (0, 1299940) -> (0.0, 0.0): 16.0576 ms
    < Exiting `<piker.ui._chart.ChartPlotWidget object at 0x7f8b66fcae60>.maxmin(name=trade_rate)`: `volume`, total time: 16.1166 ms
    > Entering `<piker.ui._chart.ChartPlotWidget object at 0x7f8b66fcae60>.maxmin(name=dark_trade_rate)`: `volume`
      volume got bars range: 0.1704 ms
      yrange mxmn: (0, 1299940) -> (0.0, 0.0): 12.8711 ms
    < Exiting `<piker.ui._chart.ChartPlotWidget object at 0x7f8b66fcae60>.maxmin(name=dark_trade_rate)`: `volume`, total time: 13.0730 ms
  > Entering `ChartView._set_yrange()`: `trade_rates`
    callback ._maxmin(): (0, 0): 29.5531 ms
    set limits: (0.0, 0.0): 0.2536 ms
  < Exiting `ChartView._set_yrange()`: `trade_rates`, total time: 29.8102 ms

Strategy to solve this: demire?

the demire streaming algo would be one impl to test which generates mx/mn output arrays for each window step:
- py code: https://github.com/lemire/pythonmaxmin/blob/master/maxmin.py
- an interesting though i had is that if you wanted to do a single pass of historical data you can in theory compute the mx/mn output for every higher level window size by recursively apply the algo on past outputs (i'll have to write more details on this thinking, but), in which case we could more or less build a sequence cache of (window_size: int, lag: int) which could be used to do a cache lookup for every zoome level? Def needs more deep thought.
- this might play well into our usage of trend calculus which requires more or less the same mx/mn computations but is agnostic to the runtime efficiency of these ops in the original paper.
exponential search techniques?
- wiki: https://en.wikipedia.org/wiki/Exponential_search
- eg code snippet: https://www.geeksforgeeks.org/exponential-search/

pikers / piker

Faster y-range sorting #325

Strategy to solve this: demire?