We have a number of places in our codebase where we optionally attach properties to a Node. 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 every Node is stable relative to its kind. This has the following implications:

• Properties of Node and its subtypes really shouldn't be "optional" and should be fully initialized when a Node is produced (even if only with undefined).
• Avoid casting nodes to things they aren't (there were several cases of node as any as JSDocContainer and node as TypeNode & { <optional properties> }).
• Move properties off of supertypes that belong on subtypes (such as symbol, localSymbol, locals, nextContainer, flowNode, etc.), as that results in unchecked node.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 than kind when the node is a supertype or union, unless the function is only accessing one or two properties (like pos/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 single Node subtype, especially if it accesses multiple properties.

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