# Rules of thumb for choosing between storing information as struct field or static parameters

**URL:** <https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202>\
**Category:** Performance\
**Created:** [April 6, 2018, 4:40pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202 "2018-04-06T16:40:56Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![favba](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/favba/32/2735_2.png) [@favba](https://discourse.julialang.org/u/favba)\
**Post date:** [April 6, 2018, 4:40pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202/1 "2018-04-06T16:40:56Z")

</div>

**TLDR** ; When is it interesting to “store” field values as static parameters instead of struct fields?  
as in

```julia
struct test{fieldA #= This is a Tuple{Int,Int}=#}
    fieldB::Vector{Int}
end

```

vs

```julia
struct test
    fieldA::Tuple{Int,Int}
    fieldB::Vector{Int}
end

```

* * *

The background for this question: I’ve coded (am coding) a pseudospectral 3D fluid flow simulator where I’m running direct numerical simulations of turbulent flow that can take hours/days. So I really don’t care about precompilation time. So, in my code I’ve gone crazy with static parameters. I’m using it for storing viscosity, wavenumber vectors(using tuples or static arrays), target cfl number, domain size… and almost every stuff that doesn’t change during the simulation. My idea is moving as many information as possible to compile time. I really don’t care about compilation time.  
But I kind of done this blindly, exploring the language, not really knowing when something like that would be usefull.  
I guess knowing for-loops ranges at compile time can lead to improvements, so that’s one rule of thumb: Store for loops ranges as static parameters. When else is it truly useful?

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [April 6, 2018, 4:53pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202/2 "2018-04-06T16:53:08Z")

</div>

> [@favba](#):
>
> When is it interesting to “store” field values as static parameters instead of struct fields?

Usually never. The goal here is to get as much information at compile time. However, when you do this every single `test` is a different type (since the concrete types are the parameterized form). This means that any array of `test` is going to not be type-stable, which actually reduces the amount of information at compile-time. So in general this kind of over-typing will backfire unless you have a good reason to do it.

Besides, you haven’t told us that indexing `fieldA` actually matters for performance. Does it? Don’t just assume it does, benchmark and profile it. Do solid development, then listen to profiling and react based on what you see.

---

<div class="post-metadata">

**Author:** ![favba](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/favba/32/2735_2.png) [@favba](https://discourse.julialang.org/u/favba)\
**Post date:** [April 6, 2018, 5:07pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202/3 "2018-04-06T17:07:48Z")

</div>

I should’ve made it clear. In my case I have a `simulation` struct. I’ll never have an array of `simulation`s. I build one `simulation` struct and call `run_simulation(my_simulation)` and that will be it (running for hours). My example was indeed totally different from my use case. I don’t have any type stability problems.  
The information I talking about are the simulations parameters, don’t truly don’t change during the simulation. Grid points, fluid viscosity, wavenumbers …

I am trying to push to the boundaries with the dynamic features of Julia. I’m trying to make this code as fast as (could it be faster??) my advisor’s highly optimized C++ code. I am considered an heretic here in the lab for not using C++ 😄

---

<div class="post-metadata">

**Author:** ![favba](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/favba/32/2735_2.png) [@favba](https://discourse.julialang.org/u/favba)\
**Post date:** [April 6, 2018, 5:09pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202/4 "2018-04-06T17:09:35Z")

</div>

But you are right: just benchmark the damn thing. 😄

---

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [April 6, 2018, 5:10pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202/5 "2018-04-06T17:10:45Z")

</div>

> [@favba](#):
>
> I’m trying to make this code as fast as (could it be faster??) my advisor’s highly optimized C++ code. I am considered an heretic here in the lab for not using C++ 😄

That’s wonderful! From my experience, it can be at least as fast as C/C++, which isn’t saying a little! 😀

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [April 6, 2018, 5:15pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202/6 "2018-04-06T17:15:34Z")

</div>

> [@favba](#):
>
> The information I talking about are the simulations parameters, don’t truly don’t change during the simulation. Grid points, fluid viscosity, wavenumbers …

Julia v0.7 will do constant propogation on literals passed into functions and will specialize compilation based on those constants, so at least after the update there will be zero need for even thinking about this. If these are truly constant, you can also just use a global `const` and the compiler will utilize this.

---

<div class="post-metadata">

**Author:** ![favba](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/favba/32/2735_2.png) [@favba](https://discourse.julialang.org/u/favba)\
**Post date:** [April 6, 2018, 5:17pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202/7 "2018-04-06T17:17:24Z")

</div>

My hope is that by moving all that information to compile time, which cannot be done in C++, I’d give Julia a head start to beat C++.  
It is almost as using Julia as a code generator, generating very specific code for every problem that I feed it. If i’m not mistaken that is the trick of FFTW, computing VERY specific DFT for the inputs.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [April 6, 2018, 6:01pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202/8 "2018-04-06T18:01:21Z")

</div>

@ChrisRackauckas is spot on. I would summarize some things you want to consider when deciding if a value should possibly be a type parameter:

1. Does dispatching on this value make sense? Would it be better/easier to just look at the value at runtime with conditionals or indexing? Don’t get too fancy with dispatch.

2. Will it be typical to have collections of values that are homogeneous with respect to this value? For example, while it’s possible with `Unitful` to have arrays like `[1m, 2m^2, 3m^-3]` it is probably more common to have vectors where the units match.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [April 6, 2018, 7:04pm UTC](https://discourse.julialang.org/t/rules-of-thumb-for-choosing-between-storing-information-as-struct-field-or-static-parameters/10202/9 "2018-04-06T19:04:57Z")

</div>

See also

> [@Overhead of dynamic dispatch?](https://discourse.julialang.org/t/overhead-of-dynamic-dispatch/7089/5):
>
> There are a number of downsides to encoding a property of your thing in the type system: There will be more time spent in compilation — every time a different type hits a different function, Julia will compile a new specialized version just for that type. If this property is typically determined by a run-time value, then many functions working with your things will be type-unstable. Type-unstable variables can stymie optimizations, cause allocations and hit dynamic dispatch. Collections of ma…