This is entirely to do with how BenchmarkTools treats expressions and global variables.

When you don’t interpolate and just ask for `@btime f(a)`

, then BenchmarkTools is measuring the performance as though you wrote `f(a)`

directly inside some function. Note, though that `a`

is a *global* and it’s not a constant — so this is a type instability! When you flag `a`

by interpolating it with a `$`

, then BenchmarkTools treats it as though it were an *argument* to that function. It becomes a type-stable local variable in the benchmarking loop.

So then you can see the extra optimization we have for small integers in such a type-unstable case. It doesn’t show up in Kristoffer’s experiment above because he made his global a `const`

(so it’s no longer type-unstable) and tested it with `@allocated`

, which works differently and wouldn’t show a type-instability in the arguments.

```
julia> a = [1.0]
1-element Array{Float64,1}:
1.0
julia> @btime f(a)
35.767 ns (1 allocation: 16 bytes)
1.0
julia> @btime f($a)
2.077 ns (0 allocations: 0 bytes)
1.0
julia> a = [1]
1-element Array{Int64,1}:
1
julia> @btime f(a)
26.699 ns (0 allocations: 0 bytes)
1
julia> @btime f($a)
2.077 ns (0 allocations: 0 bytes)
1
julia> a = [1000000]
1-element Array{Int64,1}:
1000000
julia> @btime f(a)
36.426 ns (1 allocation: 16 bytes)
1000000
julia> @btime f($a)
2.077 ns (0 allocations: 0 bytes)
1000000
```