Low-latency ComponentArrays

[visr]

Hi, I really enjoy using ComponentArrays. I used it as the state vector in OrdinaryDiffEq. One issue that we ran into was that the size of our components change for each simulation, leading to having to recompile a lot of code each time. The issue can be summarized as such:

julia> a = ComponentVector(; a=[1], b=[2,3])
julia> b = ComponentVector(; a=[1,2], b=[3])
julia> typeof(a) == typeof(b)
false

This is because the Axes keys and values are both in the type domain. I was recently discussing this on Slack with @MasonProtter, @SouthEndMusic and @ChrisRackauckas.

I made a little prototype struct CArray as a possible replacement of the current ComponentArray and I want some early feedback to see if folks would be interested in this, or point out flaws in this design.

I haven't focused yet on matching the API, but do already make sure that range, integer and nested components all work. The hope is that this can be mostly compatible, but probably still breaking. Some quick possibly flawed benchmarks show similar performance.

struct CArray{T, N, A<:DenseArray{T,N}, NT} <: DenseArray{T, N}
    data::A
    axes::NT
end

The full prototype is here: https://gist.github.com/visr/dde7ab3999591637451341e1c1166533

[jonniedie]

Yeah, I think this is a good idea. I prototyped something like this a while back when I was first writing ComponentArrays and decided against it because microbenchmarks were slightly slower and I wanted this to truly be a zero-cost abstraction. As I've come to use it more, though, I've realized that that was a mistake and it's prevented both resizable inner arrays and, maybe even more importantly, type-stable construction when there are array components. If this prototype solves those problems and is only a little slower, you'd have my vote.