Investigate possible slicing speed problem

[pp-mo]

It seems that in tests/unit/cube/test_Cube.py -v Test_slices_over many of the tests got much slower when introducing the new lazy data handling (#2364).

E.G. test_1d_slice_coord_given, taking 12sec instead of 1.7.
E.G. whole of Test_slices_over takes 75sec instead of 9.9sec.

This is decidedly peculiar, as the test data used is not lazy but a real numpy array ?

[corinnebosley]

The data used in these tests are not lazy, but somewhere down the stack this happens:

cube.slices_over(stuff):
L.2718: return self.slices(stuff)
cube.slices(stuff):
L.2790: dims_index = list(self.shape)
cube.shape(stuff):
L.1594: shape = self.lazy_data.shape

I haven't worked out yet what takes so long, but this is the only place I can see that the original tests interact with the lazy array handling.

[pp-mo]

Spot on @corinnebosley !
Speed tests seem to indicate it is the lazy_data() call, and can be fixed by avoiding creating a lazy array if you don't need it, just by testing 'self.has_lazy_data()' first.

It seems like dask has a substantially higher overhead for creating a basic wrapper object than biggus.
A quick search shows there may be other places this could have an impact.
I'll think about that a bit longer + submit a PR to improve.

[pp-mo]

See general ticket for measuring test execution times : #2371

[lbdreyer]

This needs reassessing to see whether it is still an issue

[DPeterK]

No longer a problem.