Understanding immutable type memory allocation

[Nitin Arora]

Consider the following immutable type:

immutable SCpow{T<:AbstractFloat}

  pow1au::T 

  powMin::T 

  powMax::T 

  peff::T 

  powModCoffs :: Vector{T} 

  degfac::T

end

now lets say, its defined inside a module called "FROST".

I then define a variable "SCpower" of the type "SCpow" which has the following values, inspected via "dump" as follows:

> dump(SCpower)

FROST.SCpow{Float64} 

  pow1au: Float64 10000.0

  powMin: Float64 1.0

  powMax: Float64 500.0

  peff: Float64 0.8

  powModCoffs: Array(Float64,(4,)) [1.0,0.0,0.0,0.0]

  degfac: Float64 0.02

now I want to access one of its the scalar field like this:

SCpower.pow1au

According to my limited understanding of Julia, I expect the above function to have  0 memory allocations when executed ? am I correct ? I cannot check it myself using the "@time" as putting it inside a function results in memory allocation from copying of the immutable type.

Also, if I have a nested immutable type; for example I have a "SCpower" type variable as a field of a another parent "SC" type , then will the following :

SC.SCpower.pow1au

also results in 0 memory allocations ? Also is that less efficient (assuming all types are immutable) given the nested structure ?

Pardon, if these questions sound little noobish !

Thanks a lot,

Nitin

[Kristoffer Carlsson]

Accessing a field (assuming that the field is concrete) should have zero memory allocation no matter if you have a type or an immutable. The advantage with immutabe is that (under the hood) you don't need to dereference a pointer and the compiler can do other optimizations.

Calling a function with the immutable as argument will not copy the immutable type, but instead just pass a reference to it. I actually think copy on most (all) immutables are a no-op because the whole point with immutables is that they don't change, so copying one hasn't any real purpose.

[Tim Holy]

Yes to all. The only time you'd get allocations from those operations is if
julia can't infer the type, and you've defined SCpow correctly to prevent that
from being a problem.

--Tim

[Nitin Arora]

Thanks Kris and Tim. I assume the nested immutable type reference is also efficient then?

Also, I still am confused about type argument behavior because according to the documentation:

"An object with an immutable type is passed around (both in assignment statements and in function calls) by copying, whereas a mutable type is passed around by reference."

To me that reads that immutable types are passed by copying and not be reference?

So there is a memory allocation overhead everytime we pass an immutable type and the overhead would grow with size of the type. That to me sounds like we shouldn't be using immutable types for storing large number of values.

[Yichao Yu]

You should use immutable types as array (because that's what Array is
for) but otherwise the compiler is smart enough to figure out when to
pass a immutable by reference (pointer) or by copying it. Being an
immutable type basically gives the compiler the freedom to choose
whatever it thinks is more effecient.

[Milan Bouchet-Valat]

The docs could be made more explicit about the fact that copying
semantics do not imply an actual copy is made. Nitin, would you open an
issue in GitHub about this potential docs improvement?


Regards

[Nitin Arora]

Sorry, I dropped the ball on this and missed this chain of posts over the holidays. I posted a similar questions, where I encountered this doubt again, after seeing spurious memory allocations in my code. 

I just opened an issue on GitHub for this.

https://github.com/JuliaLang/julia/issues/14801

thanks all.