issue_comments

@yohai : In short, no. It does not make sense to add a built-in function for iteration, if it is unable to augment the low-level functionality.

I'd recommend closing this PR!

Mh. Actually it looks like ndarray.flat is the fastest way to iterate over numpy. Still considerably slower than a CPython iterator though

```python import numpy

N = 1000000 a = numpy.arange(N)

def exhaust(it): for _ in it: pass

%timeit exhaust(a) 24.8 ms ± 723 µs per loop (mean ± std. dev. of 7 runs, 10 loops each) %timeit exhaust(a.flat) 20.4 ms ± 701 µs per loop (mean ± std. dev. of 7 runs, 10 loops each) %timeit exhaust(a.tolist()) 27.2 ms ± 1.16 ms per loop (mean ± std. dev. of 7 runs, 10 loops each) %timeit exhaust(range(N)) 10.5 ms ± 234 µs per loop (mean ± std. dev. of 7 runs, 100 loops each) ```

@yohai Iterating point by point in pure python over numpy data is horribly slow. numpy.ndarray.flat is there mostly to be used within cython/numba code. In a DataArray it's much worse than in a plain ndarray, because every time you invoke the slice operator to fetch a single element it's being applied to all coordinates too.

If you just need to iterate over the values of a DataArray, then DataArray.values.ravel().tolist() is the fastest option that I know of (ndarray.tolist() is much faster than list(ndarray)!). If you need the coords as well, then I suspect you may be doing it wrong - could you show a simple example of your use case?

@crusaderky @corora Thanks for your comments, glad to see that there's a more efficient way to do it. The question is do you think it's useful enough to justify adding it as a built in function. I end up using my solution quite often

Indeed this is extremely inefficient. I'm afraid it's a -1 from me.

You can get the same with a much faster one-liner: a.stack(__flat=a.dims).reset_index('__flat') (although admittedly it's more RAM-intensive). On related notes, - stack() could use a set_index=True optional parameter that avoids you from going through a MultiIndex if you don't need one - stack() should accept non-string hashables; this would allow avoiding potential collisions (e.g. flat = object()) - there is an issue with the stack -> reset_index round-trip where it converts unicode variables to object #907

@yohai It's a lot more efficient to simply iterate over the underlying array, ie. da.values.flat, if you can afford to hold everything in memory.

If you are instead using streaming computation based on dask, then you would have to do something similar on per-chunk basis.