reduce MAX_TYPEUNION_COMPLEXITY to 2

[JeffBezanson]

This helps make the compiler more efficient. In v0.6 the limit was unions with 3 elements, i.e. Union{A,B,C}. However the meaning of the variable was changed to refer to the number of 2-argument union constructors involved, so setting it to 3 allowed unions with 4 elements. This PR reduces the limit down to the same level as in v0.6.

[Keno]

Does it make sense to put this into Params?

[vtjnash]

how does Int16 get in there?

[JeffBezanson]

Does it make sense to put this into Params?

I'm not sure; this mostly controls how fast we widen when type information isn't too good, so I suspect there aren't many use cases.

[JeffBezanson]

Aha, one use of this limit was comparing with <= and another used <. That helps explain why it was set the way it was.

[JeffBezanson]

@nanosoldier runbenchmarks(ALL, vs = ":master")

[martinholters]

Ah, good catch.

[KristofferC]

Any numbers to share? Just curious (and presumably some benchmarking justified this).

[JeffBezanson]

It reduces the time to first plot by 1 second. Disappointing, but I think still makes sense since it restores what we did in 0.6. There could also very well be other cases that benefit more.

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[JeffBezanson]

@nanosoldier runbenchmarks("problem", vs = ":master")

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here. cc @ararslan

[JeffBezanson]

Ok, I think we actually need two kinds of limits here. One is on "length", i.e. Union{a, b, c, ...}, looking only inside Union types. The other is on nesting depth of unions and tuples, arising from recursion. That allows us to shorten the first limit, without excluding cases like Union{Nothing, Tuple{Union{A,B}}}.