Why is there a massive difference between collect and [range...]?

New to Julia
1 
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?

2 Likes
2

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?

2 Likes
3

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
4

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.

2 Likes
5

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.

6

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?

7

No, them being the same type doesn’t help at all.

8

Yes, it would still be a bad idea.