# On arrays with inline elements (vs pointer indirection)

**URL:** https://discourse.julialang.org/t/on-arrays-with-inline-elements-vs-pointer-indirection/88211
**Category:** General Usage
**Created:** [October 4, 2022, 7:02am UTC](https://discourse.julialang.org/t/on-arrays-with-inline-elements-vs-pointer-indirection/88211 "2022-10-04T07:02:15Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [October 4, 2022, 7:36am UTC](https://discourse.julialang.org/t/on-arrays-with-inline-elements-vs-pointer-indirection/88211/7 "2022-10-04T07:36:07Z")

</div>

> [@torrance](#):
>
> `b` is just a struct itself, with a length, dimension, capacity and pointer, and those _are_ fixed in size.

Well, not for Julia Vectors. You can `push!` and `pop!` elements onto or off from the end of Vectors (length changes, capacity always increases), for instance, and when it starts running out of the allocated space, the memory buffer is reallocated to a different bigger spot (pointer changes). But that’s not actually the general reason that mutable objects aren’t stored inline, just an Array implementation detail. For example, you _can_ make a mutable type with a fixed size: `mutable struct MutInt num::Int end`, which won’t be stored inline either.

Again, the reason is mutability. Bear in mind that Julia’s concept of mutability isn’t shared by all languages because Julia treats variables and other references like names to be attached to objects (like Python does). So you can attach two references to the same instance: `x = MutInt(3); A[1] = x`. Mutability doesn’t only mean the instance can change; if you think about it, you don’t actually need that all too often, you can just reassign variables to different instances e.g. `count += 1`. It also means that all the references access the change, so `x.num = 5` changes `x` _and_ `A[1]`. To pull that off, the actual `num` field cannot be stored directly in `x` or `A`, but in a neutral 3rd-party location on the heap or stack. By definition, `MutInt(3)` is not stored inline in `A` because some of its data is _not in A’s array buffer_.

> [@torrance](#):
>
> such that `a` is stored in the array, and the vector metadata of `b` is stored directly in the array? Meanwhile, accessing `mystruct.b[100]` for example, still requires pointer indirection, but that’s ok.

That’s essentially what happens. Very much like instances of `MyStruct` outside of arrays, the fixed-size chunk in the array’s buffer contains a `Float64` for the `a` field and a pointer for the `b` field. That’s not considered inline. I’m not actually sure where vector metadata is stored, [`Base.summarysize`](https://discourse.julialang.org/t/is-there-a-package-to-list-memory-consumption-of-selected-data-objects/85019/16) doesn’t even count that bit of memory.

---

_[View the full topic](https://discourse.julialang.org/t/on-arrays-with-inline-elements-vs-pointer-indirection/88211)._