Investigate Regression in Compilers-Unions

[DanielRosenwasser]

Our perf dashboard has a ~230ms regression on the compilers-unions benchmark starting at 4e33e0e introduced in #49865.

[DanielRosenwasser]

I think you can just fix this if you check whether the target has the appropriate primitive-like flag for the literals you're checking.

But I'm not sure.

[andrewbranch]

I don’t quite understand—the target is always a weak object type here, never a primitive.

[DanielRosenwasser]

Hm - is it possible that it has to do with the use of isLiteralType which returns true if any given type in a union is a literal? You may be doing the work of getting the apparent type of fairly large union types. The solution might be to only do the check when you have exactly a single singleton type.

I'm not that familiar with the weak type checking logic to be honest though, and maybe it'd be better to profile it.

[andrewbranch]

So, my assumption was that the perf impact was more likely to be due to actually performing more common-property checks, but the condition relation === comparableRelation && isLiteralType(source) is never actually true in Compiler-Unions, so if the benchmark is to be believed, the cost is solely due to calling isLiteralType(source) itself, which does not get the apparent type or anything expensive; it just does every((type as UnionType).types, isUnitType) over unions. We could try caching that bit on UnionType, but it seems odd that it’s really making that big of a difference here.

[DanielRosenwasser]

That's surprising. You don't really need to cache though because you'll re-enter the same branch where isRelatedTo will distribute across union types, right?

[DanielRosenwasser]

Let's see if #50423 fixes this.