swift234

Prefer solving the smallest unresolved overload sets.

When selecting an unresolved overload set to explore, start with the
overload set with the smallest number of overloads. This keeps the
solution space from branching out too quickly. It's a modest win (2%
improvement in number of constraint systems explored, 3% speedup), but
the more direct benefit is that doing the opposite (preferring the
largest number of overloads) causes a catastrophic blow-up in
type-checking time.

I get the sense that there's actually a much smarter heuristic we
could employ, based on how likely it is that a given overload set can
be resolved quickly, without much further branching.




Swift SVN r3113