We have a number of places in our codebase where we optionally attach properties to aNode. While a common practice in JS, this can sometimes have negative consequences with regards to runtime performance. Most modern JavaScript engines use Inline Caches (ICs) to optimize code paths, primarily when reading or writing to properties on objects, or to global variables.

Ideally, we want property ICs to be "monomorphic", such that they only ever see a single object shape (or "map" in V8 parlance) as "monomorphic" property ICs provide the fastest lookups. A "polymorphic" IC has slightly worse performance since it shifts from a one-to-one lookup to a short list of "map"-> property entries. If a new "map" is encountered once a polymorphic IC has around four entries, V8 will shift to a "megamporphic" IC. "Megamorphic" property ICs are the worst in terms of performance, as V8 essentially gives up on fast property access and relies on slow property lookups (there is still a cache, but it is cyclical: repeated property lookups for the same "map" will be fast but will age out as new "maps" are encountered).

Monomorphism isn't always possible, especially when accessing properties like.kind. However, in cases where we have branched on.kind, we should endeavor to ensure that further property accesses within that branch remain monomorphic, or at least polymorphic.

One way to achieve this is to ensure the shape of everyNode is stable relative to itskind. This has the following implications:

• Properties ofNode and its subtypes really shouldn't be "optional" and should be fully initialized when aNode is produced (even if only withundefined).
• Avoid casting nodes to things they aren't (there were several cases ofnode as any as JSDocContainer andnode as TypeNode & { <optional properties> }).
• Move properties off of supertypes that belong on subtypes (such assymbol,localSymbol,locals,nextContainer,flowNode, etc.), as that results in uncheckednode.symbol accesses which often result in "wrong map" deoptimizations.
• Avoid using "cover types" with a lot of optional properties in favor of union types where you must discriminate before access.
• Avoid accessing properties other thankind when the node is a supertype or union, unless the function is only accessing one or two properties (likepos/end) since a megamorphic lookup on "pos" will have the same cost as a megamorpic lookup on "kind".
• Where possible, a function or code path should try to target a singleNode subtype, especially if it accesses multiple properties.

There is a trade-off for these changes, however. Pre-defining potentially unused properties on aNode increases the memory footprint. As such, if the memory cost becomes too severe, we may want to investigate removing properties from someNode subtypes where the value can be trivially recomputed from source or moved into a cache likeNodeLinks orEmitNode.