Repository navigation
Slow iteration because of IxDyn #1340
Description
Activity
I can reproduce similar timings even when the array is contiguous ("standard layout") and the fast path (which wraps a simple slice iterator) is being used. Interestingly it appears the mere presence of the code to handle the slow case has a significant impact. This slow-case code is different and more difficult to optimize when the array has dynamic rank. When the dynamic rank array is not contiguous, the performance degrades significantly more:
1. dynamic rank contiguous. mean 340.722ms 2. dynamic rank non-contiguous. mean 1776.912ms 3. static rank contiguous. mean 99.790ms 4. static rank non-contiguous. mean 247.296ms 5. to slice. mean 38.376msHere the "non-contiguous" cases are the result of slicing the
(4320, 8468, 4)array usingslice_axis_inplace(Axis(1), Slice::new(1, None, 1)). See code. Meanwhile (5) represents doing the fastest possible thing which is amemcpy, and shows why ndarray's documentation recommends using higher-level methods first, as they allow the library to drive the iteration. See also this old post on internal versus external iteration.Reacted by bluss
As I described in #1339, an array with
IxDynhas 10x slower iteration performance than an equivalent array using a fixed-size index. This has wide-reaching implications, as this means that many pixel-wise operations are substantially slower.Example:
Let
nbe an ndarray with the shape(4320, 8468, 4).To improve the performance of arrays using
IxDyn, I suggest optimizing iteration for these arrays. Since we can see that using fixed-sized indexes is substantially faster, I suggest internally "casting" the array to a fixed-size index (or similar) before iteration when possible.