hcat is incredibly slow for more than two inputs datasets

[kahaaga]

Describe the problem

After https://github.com/JuliaDynamics/StateSpaceSets.jl/pull/32/files was merged, hcat is incredibly slow when horizontally concatenating. This is true for both Vector{<:Real} with StateSpaceSets. The operation allocates excessively and is very slow.

The hcat I had implemented before the PR was pretty fast, so I think we should just bring that back in new wrapping, so that it works for any container type.

Minimal Working Example

Illustrative example:

julia> using StateSpaceSets
julia> x = rand(10); y = rand(10, 2) |> StateSpaceSet; z = rand(10) |> StateSpaceSet;
julia> hcat(x, y, z); hcat(x, Matrix(x), Matrix(z));
Julia> using BenchmarkTools
julia> @btime hcat($x, $y, $z);
  18.833 μs (341 allocations: 10.98 KiB)
julia> @btime hcat($x, $(Matrix(y)), $(Matrix(z)));
  28.991 ns (2 allocations: 416 bytes)

hcat with state space sets is 650 times slower than hcat on matrices, which of course will have huge impacts in any code that relies on horizontal concatenation of state space sets (e.g. in Associations.jl).

Package versions

I'm using StateSpaceSets 2.3.0, but this is likely the case on all version following the PR linked above.

[kahaaga]

Update: just a simple wrapper that first converts the state space sets to a matrix, then converts back using a user-provided container type is already 9.5 times as fast and allocates 3 times less.

function merge_vector_or_statespacesets(x::VectorOrStateSpaceSet...; container = SVector)
    StateSpaceSet(hcat((xᵢ isa AbstractStateSpaceSet ? Matrix(xᵢ) : xᵢ for xᵢ in x)...); container)
end

julia> @btime hcat($x, $y, $z);
  19.041 μs (341 allocations: 10.98 KiB)
julia> @btime merge_vector_or_statespacesets($x, $y, $z);
  2.620 μs (53 allocations: 3.22 KiB)  

[kahaaga]

But this can be made much faster by bringing back the old approach of inferring the dimension up-front, pre-allocating an array to fill into, and then converting to the desired state space set container type at the end.

[Datseris]

Sure, of course you can bring back the new approach. During v2 it took a lot of time to make the code be correct, so performance was not within my time budget.

[kahaaga]

Sure, of course you can bring back the new approach. During v2 it took a lot of time to make the code be correct, so performance was not within my time budget.

Makes sense! I'll just use a convenience function upstream until this is fixed here (read: until I have time to reintroduce the old approach in a PR here).

[Datseris]

I'll just use a convenience function upstream

I don't understand. If you have this function why not put it here directly?