julia> @time k = collect(1:10^7)
0.294210 seconds (2 allocations: 76.294 MiB, 90.43% gc time)
10000000-element Vector{Int64}:
1
2
⋮
9999999
10000000
julia> @time k = [(1:10^7)...]
1.663185 seconds (30.00 M allocations: 925.627 MiB, 28.68% gc time)
10000000-element Vector{Int64}:
1
2
⋮
9999999
10000000
Why is there such a big difference? Is splat just inefficient?
The second one is a function call with 10^7 arguments while the first one is a function call with one argument. I don’t know exactly how the compiler even deals with the second case but it’s intuitively clear that it’s more difficult to optimize, no?
To elaborate on the function call comment: [x...] seems to translate to vect(x...) after de-sugaring.
Just an idle observation: If you want to make your introspection tools hang/crash try
julia> x = (1:10^7)
1:10000000
julia> @code_warntype [x...] # very unhappy trying to list 10^7 arguments
The general rule of thumb for splatting is not to use it if you don’t know the length of the thing you’re splatting at compile time/the compiler doesn’t know it (as is the case for Vector). That’s the reason why we have both min and minimum, max and maximum and so on.
I assume the compiler can still kind of deal with all those arguments because it knows they’re of the same type. Like in Vararg{Int}. But I assume if that pattern was broken (let’s say Float64 and Int interleaved for 10e7 arguments, it would be worse.
What if you know at compile time that the length is 10^7? Suppose it’s a static range. Wouldn’t it still be a bad idea to try to compile a method with that many arguments?
No, them being the same type doesn’t help at all.
Yes, it would still be a bad idea.