### Author:  [@sgaure](https://discourse.julialang.org/u/sgaure)
#### Post date: [April 22, 2024, 10:39am UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/2 "2024-04-22T10:39:43Z")
Compilation is done for functions, not individual code blocks. So if there are some kind of dependency between your `foo` and `bar1` or `bar2`, optimizations can be different. It’s hard to say what exactly happens here without further details.
---
### Author:  [@DanDoe](https://discourse.julialang.org/u/DanDoe)
#### Post date: [April 22, 2024, 12:55pm UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/3 "2024-04-22T12:55:03Z")
That is good to know!
Unfortunately, extracting a separate function `foo`
```julia
function foo()
foo
end
@trixi_timeit timer() "foo" begin
foo()
end
```
still gives the same results in terms of performance.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 22, 2024, 1:01pm UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/4 "2024-04-22T13:01:23Z")
Is it possible that in one case it is inlined and in the other case not? Did you try the `@inline` decorator?
---
### Author:  [@sgaure](https://discourse.julialang.org/u/sgaure)
#### Post date: [April 22, 2024, 1:14pm UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/5 "2024-04-22T13:14:28Z")
Alternatively, also try `@noinline`. Also, a code snippet, or a function, can behave differently if the types of variables are different.
---
### Author:  [@DanDoe](https://discourse.julialang.org/u/DanDoe)
#### Post date: [April 22, 2024, 1:30pm UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/6 "2024-04-22T13:30:19Z")
For both `b1, b2` the outer function is not inlined.
---
### Author:  [@DanDoe](https://discourse.julialang.org/u/DanDoe)
#### Post date: [April 22, 2024, 1:30pm UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/7 "2024-04-22T13:30:59Z")
Hm, `@noinline function foo()` gives the same as `@inline function foo()` and `function foo()` in terms of performance.
---
### Author:  [@sgaure](https://discourse.julialang.org/u/sgaure)
#### Post date: [April 22, 2024, 7:47pm UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/8 "2024-04-22T19:47:01Z")
So, then, are the arguments to `foo()`, and any global variables used, of the same type and size in both cases?
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [April 22, 2024, 11:10pm UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/9 "2024-04-22T23:10:27Z")
A small-enough reproducible example would be nice.
---
### Author:  [@DanDoe](https://discourse.julialang.org/u/DanDoe)
#### Post date: [April 23, 2024, 6:58am UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/10 "2024-04-23T06:58:23Z")
I have one (smaller) struct `struct1` and one superset of this, `struct2` which stores some additional quantities.
`foo()` receives instances of `struct1` and `struct2`, respectively, but all operations within `foo()` are done on the variables which both structs have.
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [April 23, 2024, 8:28am UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/11 "2024-04-23T08:28:35Z")
As long as you’re not giving us a reproducer this is just guesswork, however:
> [@DanDoe](#):
>
> the timings […] vary for the [**default optimization level 2**](https://docs.julialang.org/en/v1/manual/command-line-interface/#command-line-interface) by a factor of three, i.e., the unchanged block of code `foo` is for one case turned into machine code that is three times slower.
>
> If I, however, run the code only with `--optimize=1` the timer outputs are equal (up to system noise).
It’s expected that optimization would reorder code, that’s one of the things that optimizers do to make our code faster.
So, you’re asking “how to encourage optimizations”, but if you want reliable timers what you actually want to ask is “how to inhibit optimizations”.
---
### Author:  [@sgaure](https://discourse.julialang.org/u/sgaure)
#### Post date: [April 23, 2024, 11:23am UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/12 "2024-04-23T11:23:10Z")
With two different structs a lot of things can happen. Are they both mutable or both immutable? Are the fields you use identically declared in the structs, and concrete? A factor of 3 is quite a lot. It could be because with one of the structs it’s possible to vectorize the computation, or stack allocate, or a field you use is abstract in one of the structs, leading to bad performance. It’s hard to speculate about without an example.
---
### Author:  [@DanDoe](https://discourse.julialang.org/u/DanDoe)
#### Post date: [April 23, 2024, 1:32pm UTC](https://discourse.julialang.org/t/how-to-encourage-compiler-optimizations/113325/13 "2024-04-23T13:32:18Z")
Alright, although I am not sure whether this is helpful or not, my two structs are
```julia
# This struct is needed to fake
# https://github.com/SciML/OrdinaryDiffEq.jl/blob/0c2048a502101647ac35faabd80da8a5645beac7/src/integrators/type.jl#L77
# This implements the interface components described at
# https://diffeq.sciml.ai/v6.8/basics/integrator/#Handing-Integrators-1
# which are used in Trixi.
mutable struct Integrator{RealT <: Real, uType, Params, Sol, F, Alg,
IntegratorOptions}
u::uType
du::uType
u_tmp::uType
t::RealT
dt::RealT # current time step
dtcache::RealT # Used for euler-acoustic coupling
iter::Int # current number of time steps (iteration)
p::Params # will be the semidiscretization from Trixi
sol::Sol # faked
f::F
alg::Alg # This is our own class written above; Abbreviation for ALGorithm
opts::IntegratorOptions
finalstep::Bool # added for convenience
# stages:
k1::uType
k_higher::uType
k_S1::uType
t_stage::RealT
end
```
and
```julia
# This struct is needed to fake
# https://github.com/SciML/OrdinaryDiffEq.jl/blob/0c2048a502101647ac35faabd80da8a5645beac7/src/integrators/type.jl#L77
# This implements the interface components described at
# https://diffeq.sciml.ai/v6.8/basics/integrator/#Handing-Integrators-1
# which are used in Trixi.
mutable struct Multi_Integrator{RealT <: Real, uType, Params, Sol, F, Alg,
IntegratorOptions}
u::uType
du::uType
u_tmp::uType
t::RealT
dt::RealT # current time step
dtcache::RealT # Used for euler-acoustic coupling
iter::Int # current number of time steps (iteration)
p::Params # will be the semidiscretization from Trixi
sol::Sol # faked
f::F
alg::Alg # This is our own class written above; Abbreviation for ALGorithm
opts::IntegratorOptions
finalstep::Bool # added for convenience
# stages:
k1::uType
k_higher::uType
k_S1::uType
# Variables managing level-depending integration
level_info_elements::Vector{Vector{Int64}}
level_info_elements_acc::Vector{Vector{Int64}}
level_info_interfaces_acc::Vector{Vector{Int64}}
level_info_boundaries_acc::Vector{Vector{Int64}}
level_info_boundaries_orientation_acc::Vector{Vector{Vector{Int64}}}
level_info_mortars_acc::Vector{Vector{Int64}}
level_u_indices_elements::Vector{Vector{Int64}}
t_stage::RealT
coarsest_lvl::Int64
n_levels::Int64
end
```
where `alg::Alg` is the only argument that is different for the structures out of `RealT <: Real, uType, Params, Sol, F, Alg, IntegratorOptions`.
The function corresponding to `foo()` is given by
```julia
function k1k2!(integrator, p, c)
integrator.f(integrator.du, integrator.u, p, integrator.t)
@threaded for i in eachindex(integrator.du)
integrator.k1[i] = integrator.du[i] * integrator.dt
end
integrator.t_stage = integrator.t + c[2] * integrator.dt
@threaded for i in eachindex(integrator.u)
integrator.u_tmp[i] = integrator.u[i] + c[2] * integrator.k1[i]
end
end
```
where `@threaded` is a macro essentially equivalent to `@batch` from [Polyester.jl](https://github.com/JuliaSIMD/Polyester.jl).