issue_comments

great, thanks for taking care of that!

At least on my laptop from 2015, its was longer than 1s:

[ 25.00%] ··· Running unstacking.Unstacking.time_unstack_fast  201.44ms
[ 50.00%] ··· Running unstacking.Unstacking.time_unstack_slow  5.75s
[ 75.00%] ··· Running unstacking.UnstackingDask.time_unstack_fast 1.35s
[100.00%] ··· Running unstacking.UnstackingDask.time_unstack_slow 7.39s

so I reduced the array size and now its

[ 25.00%] ··· Running unstacking.Unstacking.time_unstack_fast  26.33ms
[ 50.00%] ··· Running unstacking.Unstacking.time_unstack_slow   594.61ms
[ 75.00%] ··· Running unstacking.UnstackingDask.time_unstack_fast  190.38ms
[100.00%] ··· Running unstacking.UnstackingDask.time_unstack_slow 809.36ms

Sorry, for the delay, I finally merged upstream. Looks like the failed builds are unrelated to my changes, so it should be ready for merging?

What about a quick fix with index.equals like this (without the prints of course): https://github.com/maahn/xarray/commit/cf83991a161fbd89af2029a69cb50f1e09a5ed45. For the example above

arr = xr.DataArray(np.empty([1, 8996, 9223]))
arr = arr.stack(flat_dim=['dim_1', 'dim_2'])
%time arr.unstack('flat_dim')

the modified routine takes 5.75 s in comparison to 6min 40s with xr 0.10.7 and pd 0.23.3. Not sure whether this is related to a newer version, but index.equals(full_idx) takes actually only 2e-4 s in that example. When slicing or reordering is applied to the MultiIndex

arr = xr.DataArray(np.arange(20).reshape((1, 10, 2))).stack(flat_dim=['dim_1', 'dim_2'])
arr.isel(flat_dim = [1,2]).unstack('flat_dim')

or

arr = xr.DataArray(np.arange(20).reshape((1, 10, 2))).stack(flat_dim=['dim_1', 'dim_2'])
arr[:,::-1].unstack('flat_dim')

it will fall back to the old method with reindex.

Thanks for the review.

Good idea, it turned out the step function was quite easy to implement by using https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes/_axes.py#L1735 So now, 1D data defaults to the standard line plot, but you can use plot.step() instead. I guess changing the default plot to something more sophisticated would make the simple logic in plot() to determine the default quite complex?

See https://gist.github.com/maahn/91da0a8d299ef6567827749cbe2f1913

Ok, I added the interval_step_plot kwarg (default True) to the 1D line plot to make a step plot with the real (i.e. not interpolated) boundaries. After that I had the feeling that it's inconsistent if line uses the real boundaries but pcolormesh doesn't. So I also patched that, but I had to disable infer_intervals for these cases. See also: https://gist.github.com/maahn/91da0a8d299ef6567827749cbe2f1913/530ed7bf77c9c3257cab46c3894c1412085a217a

Let me know what you think and I will also add some documentation.

Thanks, for the comment, but I wouldn't use center labels when using groupby_bins by default, that could be misleading in case of non-uniform (e.g. exponential) bin spacing. I guess that's acceptable for a plot, but not for a DataArray, because the information about the boundaries would be lost. And from a user perspective, I would find it a bit confusing if an additional coordinate would show up when using groupby_bins.

OK, I reported it to the matplotlib team: https://github.com/matplotlib/matplotlib/issues/6804