Understanding source of allocations when profiling

All those Any there mean that the compiler can’t figure out what type will come out of accessing V. The core problem lies in

%17 = Core.tuple(A, SA)::Tuple{Array{Float64, 3}, StructArray{S, _A, _B, _C} where {_A, _B<:Union{Tuple, NamedTuple}, _C}}
%18 = Core.tuple(B, SB)::Tuple{Array{Float64, 3}, StructArray{S, _A, _B, _C} where {_A, _B<:Union{Tuple, NamedTuple}, _C}}

because it’s here that the compiler doesn’t know enough about what kind of StructArray you’re creating. I’m kind of confused why you’d create a StructArray{S} from an Array{Float64,3} in the first place, and it seems the compiler agrees. It tries to create a common type for

V = [(A,SA),(B,SB)]

and can only come up with Any as a common super type for these two, since they’re basically both some tuple of some array and some StructArray, which only share Any as their supertype.

One way around this problem would be to create a function barier by putting everything after the creation of your StructArrays in its own function (or just create the StructArrays outside of your testfunc and pass them in, which is a little more julian and flows nicely with the common pattern of preallocating your arrays).

2 Likes