Unexpected allocation when splatting

[garrison]

I was surprised that f() allocated. I was even more surprised when I found out that g() does not:

julia> f() = CartesianIndex((@SVector[1,2,3])...);

julia> g() = CartesianIndex(Tuple(@SVector[1,2,3])...);

julia> @btime f()
  705.205 ns (8 allocations: 208 bytes)
CartesianIndex(1, 2, 3)

julia> @btime g()
  0.026 ns (0 allocations: 0 bytes)
CartesianIndex(1, 2, 3)

[andyferris]

Yes this is called the "splatting penalty".

Julia "lowers" function calls with ... in it to an internal function called apply. As an internal function it knows how to deal with tuples but otherwise falls back to the iteration protocol (constructing an intermediate boxed tuple).

This can be a bit surpising since it (a) works correctly, (b) ... in slurping and destructuring there is no such efficiency problem, and (c) Julia does a pretty good job of avoiding performance gotchas in general. Fixing this would be the realm of the compiler developers, unfortunately. As you noted, the second one works fine; @c42f even suggested to have "lowering" wrap splats into an overloadable generic function that constructs a tuple from an iterable so you essentially always get the second case, which is an idea I have been warming to.

[c42f]

Right on Andy. See JuliaLang/julia#29114 for an extended discussion.

Summary: type inference needs to model the iteration protocol because splatting is defined in terms of iteration. (There's other implementation options, but they all seem to have some undesirable properties.)