# Arrays of NamedTuples

**URL:** <https://discourse.julialang.org/t/arrays-of-namedtuples/120910>\
**Category:** Performance\
**Tags:** question\
**Created:** [October 4, 2024, 12:50pm UTC](https://discourse.julialang.org/t/arrays-of-namedtuples/120910 "2024-10-04T12:50:23Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![kingaa](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kingaa/32/212405_2.png) [@kingaa](https://discourse.julialang.org/u/kingaa)\
**Post date:** [October 4, 2024, 12:50pm UTC](https://discourse.julialang.org/t/arrays-of-namedtuples/120910/1 "2024-10-04T12:50:23Z")

</div>

I’m designing a package based on manipulating arrays of NamedTuples. Should I be aware of any performance pitfalls associated with such structures? In particular, while many use cases will have NamedTuples, the elements of which are of primitive type, I envision applications in which the elements are more complex, and non-constant in size.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [October 4, 2024, 1:17pm UTC](https://discourse.julialang.org/t/arrays-of-namedtuples/120910/2 "2024-10-04T13:17:14Z")

</div>

yes, you should use Struct of Array representation, for example, see, ~~StructArrays.jl~~ or AwkwardArray.jl

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [October 4, 2024, 1:29pm UTC](https://discourse.julialang.org/t/arrays-of-namedtuples/120910/3 "2024-10-04T13:29:49Z")

</div>

> [@kingaa](#):
>
> I envision applications in which the elements are more complex, and non-constant in size.

Here, StructArrays won’t help much I think.

But together, array-of-namedtuples and structarray-of-namedtuples should fit all cases: just choose whether you want row-based or column-based storage, they have the exact same interface (:

> [@kingaa](#):
>
> Should I be aware of any performance pitfalls associated with such structures?

These are convenient and performant datastructures, they work just fine in Julia! “Primitive” (isbits) types are stored inline, non-constant size values are stored as pointers.  
Further recommendations would depend on the specifics of your usecase…