# Could separating private attribute access help performance?

**URL:** <https://discourse.julialang.org/t/could-separating-private-attribute-access-help-performance/64881>\
**Category:** Internals & Design\
**Created:** [July 18, 2021, 9:15pm UTC](https://discourse.julialang.org/t/could-separating-private-attribute-access-help-performance/64881 "2021-07-18T21:15:38Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [July 18, 2021, 9:15pm UTC](https://discourse.julialang.org/t/could-separating-private-attribute-access-help-performance/64881/1 "2021-07-18T21:15:38Z")

</div>

Suppose Julia distinguished between private and public attributes

```julia
struct Foo
  @public u
  a
  b
end

```

so that public access `x.u` was allowed but access to private attributes from outside the module needed

```julia
getprivate(x, :a)
@privates x.a + x.b

```

I think this could be nice for distinguishing public from private API.

My question is: could this help the compiler make optimizations, since it could tell statically that I’m not accessing any private properties?

---

<div class="post-metadata">

**Author:** ![gbaraldi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gbaraldi/32/22101_2.png) [@gbaraldi](https://discourse.julialang.org/u/gbaraldi)\
**Post date:** [July 19, 2021, 1:17am UTC](https://discourse.julialang.org/t/could-separating-private-attribute-access-help-performance/64881/2 "2021-07-19T01:17:47Z")

</div>

I’m not an expert, but I don’t think it would change anything. Why would keeping fields behind a private barrier make it easier to know more? If you can still change them via a `getprivate` function then they aren’t constant, and also a struct is immutable anyway.

---

<div class="post-metadata">

**Author:** ![colintbowers](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/colintbowers/32/8033_2.png) [@colintbowers](https://discourse.julialang.org/u/colintbowers)\
**Post date:** [July 19, 2021, 2:58am UTC](https://discourse.julialang.org/t/could-separating-private-attribute-access-help-performance/64881/3 "2021-07-19T02:58:10Z")

</div>

I’m no expert either but my understanding is that the key feature from a compiler optimization perspective is whether it is mutable/immutable. That is, the key thing the compiler needs to know ahead of time is whether the type can change, rather than the value. And this is already taken care of by `struct` versus `mutable struct`. Probably an over-simplification, but from the compilers point of view, it doesn’t really matter whether your `Float64` takes value `1.0` or `2.0`. All that matters is knowing ahead of time that it definitely will be a `Float64`.

The optimizations for things like `StaticArrays` come from the fact that something that is able to be mutated in a normal `Vector` (the length) is known to be fixed ahead of time in a `StaticArray`. Again, it doesn’t matter what values are in the `Vector` or `StaticArray`. All that matters is whether it can be treated as mutable/immutable.