Benchmark and optimize PyArray2/3::from_vec2/3

[adamreichold]

Follow-up to #291. Admittedly, performance conscious code will probably try to avoid these methods, but it is relatively straight-forward to optimize them, as using pointer traversal instead of indexing brings a large improvement

 name              main ns/iter  indexing ns/iter  diff ns/iter   diff %  speedup 
 from_vec2_large   435,855       10,061                -425,794  -97.69%  x 43.32 
 from_vec2_medium  6,699         507                     -6,192  -92.43%  x 13.21 
 from_vec2_small   702           325                       -377  -53.70%   x 2.16 
 from_vec3_large   303,579       7,109                 -296,470  -97.66%  x 42.70 
 from_vec3_medium  38,732        3,000                  -35,732  -92.25%  x 12.91 
 from_vec3_small   950           410                       -540  -56.84%   x 2.32 

and optimizing for T::IS_COPY elements is then a bit of a mixed bag on top of this

 name              indexing ns/iter  copying ns/iter  diff ns/iter   diff %  speedup 
 from_vec2_large   10,061            10,265                    204    2.03%   x 0.98 
 from_vec2_medium  507               527                        20    3.94%   x 0.96 
 from_vec2_small   325               317                        -8   -2.46%   x 1.03 
 from_vec3_large   7,109             7,084                     -25   -0.35%   x 1.00 
 from_vec3_medium  3,000             1,735                  -1,265  -42.17%   x 1.73 
 from_vec3_small   410               404                        -6   -1.46%   x 1.01 

I suspect that this is due to the innermost slices being too short for the overhead of calling ptr::copy_nonoverlapping to amortize itself, but I think we can still keep as it not making things significantly worse and might help in specific cases of large rows and should not add code bloat due to T::IS_COPY being resolved at compile time.

[adamreichold]

Not doing an upfront pass to check for ragged arrays brings another single digit percentage win:

 name              copying ns/iter  single-pass ns/iter  diff ns/iter   diff %  speedup 
 from_vec2_large   10,265           9,897                        -368   -3.58%   x 1.04 
 from_vec2_medium  527              501                           -26   -4.93%   x 1.05 
 from_vec2_small   317              314                            -3   -0.95%   x 1.01 
 from_vec3_large   7,084            6,943                        -141   -1.99%   x 1.02 
 from_vec3_medium  1,735            1,548                        -187  -10.78%   x 1.12 
 from_vec3_small   404              395                            -9   -2.23%   x 1.02 

[davidhewitt]

This plus #291 is very cool - always nice to deliver performance improvements! Just a few random thoughts.

[davidhewitt]

It looks like the implementation for FromIterator for boxed slices just goes through Vec anyway, so do we really need the from_exact_iter variant?

https://doc.rust-lang.org/src/alloc/boxed.rs.html#1880-1884

[adamreichold]

My initial aim was to avoid changing the API, but since from_*iter is probably not the most used API and we are still at version 0.x, this does not really seem to be appropriate.

As for using Box<[_]> instead of Vec<_>, I was thinking that the exact case will not end up with excess capacity and hence could go from vec to boxed slice without re-allocation. But this is not really useful as a boxed slice and a vec without excess capacity will basically end up creating the same PySliceContainer instance.

Hence, I'll add a commit removing the from_exact_iter method as any specializations that the standard library provides with pass through the generic signature of from_iter in any case.

[adamreichold]

@davidhewitt Please let me know if changing API is alright without before I merge. Thanks!

[davidhewitt]

Happy with this as-is, though I do prefer deprecating where possible myself.