# Row vs. column major for arrays of coordinate vectors
**URL:** https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297
**Category:** Performance
**Created:** [July 7, 2021, 8:48pm UTC](https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297 "2021-07-07T20:48:03Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@pavanakumar](https://discourse.julialang.org/u/pavanakumar)
#### Post date: [July 7, 2021, 8:48pm UTC](https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297/1 "2021-07-07T20:48:03Z")
There is one advantage that I can think of with column major storage for geometry (coordinate storage). 1D, 2D and 3D coordinates can be represented without hassle. A row-major format will require variable stride (1 in 1D, 2 in 2D and 3 in 3D) to access the coordinate value. But it is always fixed (stride of 1) in the case of column major formats.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [July 7, 2021, 8:57pm UTC](https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297/2 "2021-07-07T20:57:32Z")
No, this is the same for both formats — it simply depends on whether the coordinate vectors are stored in the rows or columns.
In any case, in Julia I would typically recommend [using StaticArrays.jl](https://docs.julialang.org/en/v1/manual/performance-tips/#Consider-StaticArrays.jl-for-small-fixed-size-vector/matrix-operations) for 1d/2d/3d coordinate vectors, in which case you store an array of coordinates as a 1d array of `SVector`s instead of a 2d array.
---
### Author:  [@pavanakumar](https://discourse.julialang.org/u/pavanakumar)
#### Post date: [July 7, 2021, 9:48pm UTC](https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297/3 "2021-07-07T21:48:54Z")
> [@stevengj](#):
>
> it simply depends on whether the coordinate vectors are stored in the rows or columns.
Is this not row vs. column major?
x\_{i,j} = \{x\_{i}\}\_j = x(i,j) (i=dim, j = #of points)
> [@stevengj](#):
>
> as a 1d array of `SVector` s instead of a 2d array.
May not be optimal in many situations (the AoS vs. SoA debate)
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [July 8, 2021, 2:43pm UTC](https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297/4 "2021-07-08T14:43:46Z")
> [@stevengj](#):
>
> In any case, in Julia I would typically recommend [using StaticArrays.jl](https://docs.julialang.org/en/v1/manual/performance-tips/#Consider-StaticArrays.jl-for-small-fixed-size-vector/matrix-operations) for 1d/2d/3d coordinate vectors, in which case you store an array of coordinates as a 1d array of `SVector` s instead of a 2d array.
Why not just tuples?
---
### Author:  [@jishnub](https://discourse.julialang.org/u/jishnub)
#### Post date: [July 8, 2021, 3:00pm UTC](https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297/5 "2021-07-08T15:00:33Z")
`StaticArray`s are wrappers around `Tuple`s that have extra array-like behavior defined for them, eg. vector addition, matrix multiplication etc. For coordinates, to take an example, this makes it easy to transform between reference frames.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [July 8, 2021, 3:15pm UTC](https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297/6 "2021-07-08T15:15:33Z")
You could, but you would need to add your operations, e.g. addition, as tuples do not have it defined. It could work, but you might/likely will leave out operations you do now know about (ok if you don’t need them, until you do).
```julia
julia> supertype(SVector)
StaticVector (alias for StaticArray{Tuple{S}, T, 1} where {S, T})
julia> supertype(StaticArray)
AbstractArray
vs.
julia> supertype(NTuple) # also for Tuple
Any
```
It’s useful for all `Array`s and `Vector`s to derive from `AbstractArray` (rather than only `Any`). I trust what the operations you need are as fast as possible with StaticArrays.jl, you wouldn’t do better, the only slight downside to defining more operations in the package than you think you need is startup-overhead:
```julia
julia> @time using StaticArrays
0.957173 seconds (2.18 M allocations: 156.695 MiB, 1.31% compilation time) # in 1.8, down from 2.05 sec in 1.6.0
```
It seems it could do better with startup overhead, and there are ways for that.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [July 8, 2021, 6:48pm UTC](https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297/7 "2021-07-08T18:48:59Z")
> [@pavanakumar](#):
>
> Is this not row vs. column major?
No. You can choose to put your 3d coordinate vectors in `A[i,:]` (e.g. `A` is N\times3) or `A[:,i]` (3\times N). Row vs. column major is about how the resulting arrays are _stored_ in memory. So, if you want the components to be consecutive in row-major, you use `A[i,:]`, whereas if you want them to be consecutive in column-major, you use `A[:,i]`.
> [@pavanakumar](#):
>
> _[Arrays of `SVector`s]_ may not be optimal in many situations (the AoS vs. SoA debate)
Typical applications using 1d/2d/3d coordinate vectors access multiple components together frequently (e.g. for performing vector operations), in which case an array of `SVector` (AoS) is a good choice.
---
### Author:  [@piever](https://discourse.julialang.org/u/piever)
#### Post date: [July 8, 2021, 8:47pm UTC](https://discourse.julialang.org/t/row-vs-column-major-for-arrays-of-coordinate-vectors/64297/8 "2021-07-08T20:47:02Z")
> [@stevengj](#):
>
> > [@pavanakumar](#):
> >
> > _[Arrays of `SVector` s]_ may not be optimal in many situations (the AoS vs. SoA debate)
>
> Typical applications using 1d/2d/3d coordinate vectors access multiple components together frequently (e.g. for performing vector operations), in which case an array of `SVector` (AoS) is a good choice.
With the latest release of [StructArrays](https://github.com/JuliaArrays/StructArrays.jl/), you can have have a `StructArray{SVector}` which behaves like `Array{SVector}` (`v[i]` gives you the i-th `SVector`) but is stored as a SoA. If you need both to access the “component vectors” as well as the individual `SVector`s in an efficient way, it can probably be a good compromise.
Just realized the above sounds a bit abstract. More concretely you can do things like:
```julia
julia> using StructArrays, StaticArrays, BenchmarkTools
julia> s = StructArray(SVector(1, 2) for _ in 1:10);
julia> @btime StructArrays.components($s)
1.300 ns (0 allocations: 0 bytes)
([1, 1, 1, 1, 1, 1, 1, 1, 1, 1], [2, 2, 2, 2, 2, 2, 2, 2, 2, 2])
julia> @btime $s[3]
1.600 ns (0 allocations: 0 bytes)
2-element SVector{2, Int64} with indices SOneTo(2):
1
2
```