50x regression in copying large custom arrays.

[LilithHafner]

using Random, BenchmarkTools

struct MyArray{T, N} <: AbstractArray{T, N}
    data::Array{T, N}
end
Base.size(a::MyArray) = size(a.data)
Base.getindex(a::MyArray, i...) = getindex(a.data, i...)
Base.setindex!(a::MyArray, v, i...) = setindex!(a.data, v, i...)
Base.similar(a::MyArray) = MyArray(similar(a.data))
Base.IndexStyle(::Type{<:MyArray}) = IndexLinear()

x = MyArray(rand(40_000));
@btime copy($x);
#  13.084 μs (2 allocations: 312.55 KiB)  # 1.9
#  13.291 μs (2 allocations: 312.55 KiB)  # 1.10
#  459.667 μs (2 allocations: 312.55 KiB) # 58030da3bc4e6790d7bafe66d5f37b382dd6df3c (right before #50824)
#  813.792 μs (3 allocations: 312.56 KiB) # 140ea94f8e (current master)

versioninfo()
# Julia Version 1.11.0-DEV.857
# Commit 140ea94f8e (2023-11-07 18:58 UTC)
# Platform Info:
#   OS: macOS (arm64-apple-darwin22.4.0)
#   CPU: 8 × Apple M2
#   WORD_SIZE: 64
#   LLVM: libLLVM-15.0.7 (ORCJIT, apple-m1)
#   Threads: 1 on 4 virtual cores
# Environment:
#   JULIA_EDITOR = code

This regression was caused by multiple commits and I have not performed a bisection. However, I suspect that #50824 (cc @oscardssmith and @vtjnash) is involved (because it's involved in everything) and #49827 (cc @Tokazama) because that is the last commit that touched the isassigned code which profiling indicates is the bottleneck here.

[vtjnash]

Probably #51760

[nsajko]

Profiling shows most of the time is spend in the Array setindex!, so I guess this is caused by bounds checks. Possibly related (?): #54116

[nsajko]

Flamegraph:

[nsajko]

A workaround (and probably a good practice anyway) here is to specialize copyto! for the custom array type. Example: after JuliaArrays/FixedSizeArrays.jl#23, copying FixedSizeArrays is as fast as copying Arrays.

[oscardssmith]

should be closed by #54332