Performance/type inference regression from #12327

[simonster]

It occurs to me that, in the heterogeneous key/value type case, #12327/#12261 causes us to lose type information. Consider basically any code that uses the for (k, v) in dict idiom, e.g.:

function f(a)
    x = 0
    for (k, v) in a
        x += v
    end
    x
end

Now consider what happens if the key and value types aren't the same. Previously, because we do fancy things for tuple destructuring, we could infer that k is of the key type K and v is of the value type V. But we don't do these fancy things for Pair destructuring. code_warntype(f, (Dict{Float64,Int},)) shows that now we can only determine that k and v are both of type Union{K,V}. For the benchmark:

d = Dict([rand() => rand(Int) for i = 1:10000000]);
@time f(d)

On 6c34bc7 I get:

  0.476170 seconds (30.00 M allocations: 457.764 MB, 6.70% gc time)

On the 0.3 branch I get:

elapsed time: 0.127657036 seconds (96 bytes allocated)

[carnaval]

As a short term solution you could add an indexed_next thing for pairs, as well as the corresponding hack in inference.jl.

I have some ideas on how to solve this more generally (this is the same problem as the getindex(::Fact,::Symbol) non leaf return types for matrix factorizations) but it's not gonna happen soon :-)

[StefanKarpinski]

Would it help of Pair were defined this way instead:

immutable Pair{A,B}
    pair::Tuple{A,B}
end

That way the Pair type might inherit some of the fancy destructuring for tuples.

[simonster]

That might work, but it might not be great for non-isbits since it's an extra object and pointer indirection.