Concatenation is slower than it could be

[jebej]

This is an issue on 0.5.1 and 0.6:

__ this was not an inference issue, the case below was updated to reflect that __

function test1(N::Integer)
    return [1;1:N]
end
function test2(N::Integer)
    A = Vector{Int}(undef, N+1)
    A[1] = 1
    A[2:end] = 1:N
    return A
end
using BenchmarkTools
test1(20) == test2(20)
@benchmark test1(20)
@benchmark test2(20)

julia> test1(20) == test2(20)
true

julia> @benchmark test1(20)
BenchmarkTools.Trial:
  memory estimate:  2.25 KiB
  allocs estimate:  49
  --------------
  minimum time:     19.282 μs (0.00% GC)
  median time:      19.905 μs (0.00% GC)
  mean time:        20.430 μs (0.00% GC)
  maximum time:     98.278 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     1

julia> @benchmark test2(20)
BenchmarkTools.Trial:
  memory estimate:  256 bytes
  allocs estimate:  1
  --------------
  minimum time:     63.902 ns (0.00% GC)
  median time:      70.512 ns (0.00% GC)
  mean time:        76.032 ns (5.29% GC)
  maximum time:     571.020 ns (72.77% GC)
  --------------
  samples:          10000
  evals/sample:     988

[jebej]

This bug is making speye very slow.

[TotalVerb]

This doesn't look like an inference problem.

[jebej]

Shouldn't the compiler know A is a vector of ints?

[TotalVerb]

There's no longer an A by the time inference runs; it's optimized out. All of the intermediate expressions have been inferred.

[StefanKarpinski]

To clarify what @TotalVerb is saying – the fact that A has type Any in the type warn output is a red herring (misleading clue) since A doesn't actually appear anywhere in the code, which is the only reason it doesn't get a type annotation – what is the type of a variable that doesn't exist?

I would note that in either function, calling collect is quite unhelpful here – it would be far better to let the values be generated on-demand. The second version seems to manage to optimize away the creation of collect(1:N) entirely. Unfortunately, removing the collect from test1 doesn't fix the performance issue either.

[KristofferC]

Ref #21281, #20801

[jebej]

I see, thanks for the explanation, I've updated the OP.

[jebej]

Any idea what the issue is here? This is still a problem on release 0.6

[mbauman]

Somewhat better on 1.4-dev:

julia> @benchmark test1(20)
BenchmarkTools.Trial:
  memory estimate:  928 bytes
  allocs estimate:  17
  --------------
  minimum time:     1.113 μs (0.00% GC)
  median time:      1.408 μs (0.00% GC)
  mean time:        1.464 μs (4.21% GC)
  maximum time:     317.081 μs (99.30% GC)
  --------------
  samples:          10000
  evals/sample:     10

julia> @benchmark test2(20)
BenchmarkTools.Trial:
  memory estimate:  256 bytes
  allocs estimate:  1
  --------------
  minimum time:     49.606 ns (0.00% GC)
  median time:      54.791 ns (0.00% GC)
  mean time:        59.367 ns (4.12% GC)
  maximum time:     676.165 ns (88.80% GC)
  --------------
  samples:          10000
  evals/sample:     987

So we're only ~20x slower than ideal, instead of ~300x. Progress! (I updated the OP with the undef syntax for 1.x).