# Compilation of a function with constant arguments

**URL:** <https://discourse.julialang.org/t/compilation-of-a-function-with-constant-arguments/105168>\
**Category:** General Usage\
**Tags:** question, compilation, jit\
**Created:** [October 19, 2023, 9:46am UTC](https://discourse.julialang.org/t/compilation-of-a-function-with-constant-arguments/105168 "2023-10-19T09:46:42Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![vvbond](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vvbond/32/10105_2.png) [@vvbond](https://discourse.julialang.org/u/vvbond)\
**Post date:** [October 19, 2023, 9:46am UTC](https://discourse.julialang.org/t/compilation-of-a-function-with-constant-arguments/105168/1 "2023-10-19T09:46:42Z")

</div>

I struggle to understand the following behaviour of Julia’s compilation process: according to the `@time` output, the sum of squares function defined below is _not_ compiled when called with a constant argument.

I wonder what exactly is going on here.

```julia
julia> Σsquares(n) = let s=0
       for i in 1:n
           s += i*i
       end
       s
       end
Σsquares (generic function with 1 method)

julia> const n = 1_000_000
1000000

julia> @time Σsquares(n)
  0.000000 seconds
333333833333500000

julia> @time Σsquares(10n)
  0.000000 seconds
1291990006563070912

julia> @time Σsquares(100n)
  0.000001 seconds
672921401752298880

julia> k = 1_000_000
1000000

julia> @time Σsquares(k)
  0.004474 seconds (143 allocations: 6.984 KiB, 99.68% compilation time)
333333833333500000

```

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [October 19, 2023, 11:45am UTC](https://discourse.julialang.org/t/compilation-of-a-function-with-constant-arguments/105168/2 "2023-10-19T11:45:30Z")

</div>

I think this is Julia’s compiler acting before the benchmark code can. As `@time`’s docstring states:

> In some cases the system will look inside the `@time` expression and compile some of the called code before execution of the top-level expression begins. When that happens, some compilation time will not be counted. To include this time you can run `@time @eval ...` .

`@time` didn’t measure compilation times separately in the past, and the feature was introduced to separate it from the execution time of interest, not measure all of the compilation. There is a workaround at least, though I don’t know how `@eval` prevents the compiler from acting too soon if the code ran in the global scope to begin with.