Define copy on SubArray to fallback on getindex

[mkborregaard]

Defines a fallback function for copy on a SubArray that relegates to getindex. This is under the assumption that the type of a.parent may have an optimised method for getindex defined. In this case it resolves the issue reported here: https://github.com/JuliaLang/julia/issues/21796#issuecomment-456536706 , where @mbauman suggested opening this as a general PR on SubArray. A smaller less impactful change would be to only define it for SubArray{<:SparseMatrixCSC}.
With and without this PR:

using SparseArrays, BenchmarkTools
c = sprand(Bool,6000,18000, 0.01);
d = view(c, 1:6000, rand(1:18000, 1800));
@btime copy($d)
#  2.459 s (8 allocations: 18.59 MiB)

Base.copy(a::SubArray) = a.parent[a.indices...]
@btime copy($d)
#  210.270 μs (6 allocations: 967.27 KiB)

a 10,000x speedup at no cost.
cc @KlausC who told me he was working on something that would have the same implementation for SparseArrays.

[mbauman]

I think this is a very worthwhile change. But I don't think this should be backported as it does have the possibility of changing behaviors for some array types.

A more specific

Base.copy(a::SubArray{<:Any,<:Any,<:SparseArray}) = a.parent[a.indices...]

would be fine to backport as a performance improvement, though.

[mkborregaard]

Happy to add that but a bit unsure how to go about it - separate PR adding that? Would that entail changes to this one?

[mbauman]

No, let's keep this one as-is. I'll defer to @KristofferC and @ararslan on how they'd prefer a backport to look, but it should probably be a separate PR to either master (since the two definitions can gracefully co-exist) or directly into one of their backports branches.

[ararslan]

A separate PR to master is the easiest.

[mkborregaard]

OK - like this? #30895

[mkborregaard]

Yay, all tests passed - is there anything more I need to do here (eg add a benchmark somewhere) or is it gtg?

[mbauman]

We don't test this in BaseBenchmarks currently, but we could add a few tests there in the future.

[mkborregaard]

Great, thanks a lot for the help with this