augment review

that's previously been a deopt due to the type assignment and verification. do you have an IR render that shows it's ok? i used to use irhydra, and then deoptigate to verify that path.

that's previously been a deopt due to the type assignment and verification.

This is possible because the variable item become megamorphic: If the property read site sees more than four different class shapes, it is known as Megamorphic and is always handled by the slow path.

do you have an IR render that shows it's ok? i used to use irhydra, and then deoptigate to verify that path.

no, sorry

the item isn't megamorphic when the deopt occurs, it's actually early in the life cycle and the has() is a strategy for a long running instance.

you're basically swapping the in operator for an identity check. there's no obvious gain from it from a design pov, but engines evolve so i'm curious if it's still an issue.

to clarify; i already did that work, so if you want to land the change you would need to do the new work to show it's safe.

i should also clarify, that the items object does go megamorphic eventually (depending on usage), but the current code is still faster than a Map or other assumed optimizations based on how those structs are implemented.

you need a good reason to propose a subtle, but significant change, and benchmarks.