Kavon Farvardin ce04b84489 Fix a performance issue when answering "is this tuple Copyable"? ...

If we don't split up the tuple into individual constraints,
we end up spending more time querying whether a tuple is
Copyable in `lookupConformance`, because it will naively
check the types of all elements of the tuple recursively
with `lookupConformance`.

This is inefficient because if we know some of the elements
of the tuple are fixed types, we don't need to keep checking
those again. For example, if we have `($T, Int, $U)`, and
then try a binding for `$T`, we might ask again if the whole
tuple conforms. Leading to `lookupConformance` to check
whether `Int` (and all other elements of the tuple) conforms
to Copyable, when we either already know that, or can't
answer it yet because it's still a type variable.

By splitting up a Copyable constraint on a tuple into
invidivual  constraints on each of its type elements,
we can avoid this redundant work by `lookupConformance`.

While today we could short-cut this even further to say
that _all_ tuples are Copyable, since we emit an error if
a noncopyable type appears in one, that won't be true in
the near future. This is the nicer solution we'll want to
keep around long-term.

After discussing this with Pavel, we don't think there's a
good way to add a regression test for this, because the
performance issue primarily comes up in specific example
programs that aren't amenable to scale tests.

resolves rdar://107536402

2023-05-04 14:53:48 -07:00

589 KiB

Raw Blame History

View Raw