# Optimizing Calculation in Julia compared to C (New to Julia)

**URL:** <https://discourse.julialang.org/t/optimizing-calculation-in-julia-compared-to-c-new-to-julia/32723>\
**Category:** Performance\
**Created:** [December 26, 2019, 7:30pm UTC](https://discourse.julialang.org/t/optimizing-calculation-in-julia-compared-to-c-new-to-julia/32723 "2019-12-26T19:30:00Z")\
**Posts on this page:** 1\
**Showing post:** 24

<div class="post-metadata">

**Author:** ![bashonubuntu](https://avatars.discourse-cdn.com/v4/letter/b/f19dbf/32.png) [@bashonubuntu](https://discourse.julialang.org/u/bashonubuntu)\
**Post date:** [January 1, 2020, 6:51pm UTC](https://discourse.julialang.org/t/optimizing-calculation-in-julia-compared-to-c-new-to-julia/32723/24 "2020-01-01T18:51:05Z")

</div>

> [@Summing arrays efficiently](https://discourse.julialang.org/t/summing-arrays-efficiently/15338):
>
> N = 1024 ^ 2; A = [ones(N), ones(N), ones(N), ones(N)]; The naive way of summing the arrays in A would be to do sum(A). However, note the performance: julia\> @btime sum(A); 7.968 ms (6 allocations: 24.00 MiB) It unnecessarily allocates an array of size N for each addition (3x8 MB). Is there a way around this, or is the recommended approach to write a for loop, i.e.: julia\> @btime (S = copy(A[1]); for B in A[2:end]; S .+= B; end; S); 4.818 ms (13 allocations: 8.00 MiB)

You may find the discussion above helpful. Especially, the comment made by @baggepinnen

> [@loki](#):
>
> That might be also true of @codewarntype but I am not that familiar with that package. To over come this I’ve been using @profiler to get a better sense of whats going on.

Re `@codewarntype`, it’s just a helpful quick-way to check for all type-instabilities like so

```julia
julia> function f(x, y)
        return x + y
       end
f (generic function with 1 method)

julia> @code_warntype f(1, 2)
Variables
  #self#::Core.Compiler.Const(f, false)
  x::Int64
  y::Int64

Body::Int64
1 ─ %1 = (x + y)::Int64
└── return %1

julia> @code_warntype f(1.0, 2.0)
Variables
  #self#::Core.Compiler.Const(f, false)
  x::Float64
  y::Float64

Body::Float64
1 ─ %1 = (x + y)::Float64
└── return %1

julia> x = 1
1

julia> y = 2
2

julia> function g()
        return x + y
       end
g (generic function with 1 method)

julia> @code_warntype g()
Variables
  #self#::Core.Compiler.Const(g, false)

Body::Any
1 ─ %1 = (Main.x + Main.y)::Any
└── return %1

```

In the above example, `f(x, y)` is type-stable (all types are known at compile-time) but `g()` is not as the return type is not known at compile time. The `Any` in the `@code_warntype` output for `g()` will likely show up in your REPL in red. The reason is that in `f(x,y)` I pass x, y as arguments but they are global variables for the function `g()`.

Notice that for all functions a specialized compiled code is generated depending on your argument type. `@code_warntype` simply allows you to see that. Please keep in mind that all type-instabilities are not important as mentioned in the link below. There are some functions in `Base` like `Base.getindex` which are type-unstable by design. Similarly, the iterator interface for a for loop will also be type-unstable and so on. So don’t worry about all type-instabilities!

[https://docs.julialang.org/en/v1/manual/performance-tips/#man-code-warntype-1](https://docs.julialang.org/en/v1/manual/performance-tips/#man-code-warntype-1)

---

_[View the full topic](https://discourse.julialang.org/t/optimizing-calculation-in-julia-compared-to-c-new-to-julia/32723)._