# Immutable vs Type: reassignment via arrays and performance

**URL:** https://discourse.julialang.org/t/immutable-vs-type-reassignment-via-arrays-and-performance/3364
**Category:** General Usage
**Tags:** question
**Created:** [April 25, 2017, 2:51am UTC](https://discourse.julialang.org/t/immutable-vs-type-reassignment-via-arrays-and-performance/3364 "2017-04-25T02:51:25Z")
**Posts on this page:** 1
**Showing post:** 10

<div class="post-metadata">

### Author: ![jameson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jameson/32/23_2.png) [@jameson](https://discourse.julialang.org/u/jameson)
#### Post date: [April 25, 2017, 5:58pm UTC](https://discourse.julialang.org/t/immutable-vs-type-reassignment-via-arrays-and-performance/3364/10 "2017-04-25T17:58:02Z")

</div>

> [@ChrisRackauckas](#):
>
> But Ref exists for this reason

Not to be overly pedantic, but that’s not why Ref was added. It was specifically added to act like a `view` operation on one element, primarily for aiding in C-interop. In fact, it is an abstract type specifically because that allows it to perform its intended function (despite also making it sub-optimal as a annotation for making a field mutable).

From a performance standpoint, it’s usually best if you make the whole object immutable, or the whole object mutable. It’s better (performance and memory) to wrap an entire immutable object in a mutable object (including in a mutable struct or an Array), rather than using Ref (or RefValue or Array or another mutable type) to select multiple specific fields to make mutable. This flattens out the memory hierarchy, meaning the computer needs to do fewer memory fetches to compute the answer.

---

_[View the full topic](https://discourse.julialang.org/t/immutable-vs-type-reassignment-via-arrays-and-performance/3364)._