I added this primarily to catch an unconditional cast toSymbolLinks fromSymbol and decided to leave it in to prevent that from happening in the future.

Does using a class mean instances of SymbolLinks will share the same hidden class even if different properties are attached in different orders? If not, how bad is the memory impact of initializing all the possible properties toundefined? (I assume awful because there are so many.) Did you test the class implementation against an object literal implementation?

Also, what’s the reason for using a class expression here?

A class declaration would conflict with the interface of the same name. It also lets me remove a cast toany athttps://github.com/microsoft/TypeScript/pull/51880/files?show-viewed-files=true&file-filters%5B%5D=#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R2573 andhttps://github.com/microsoft/TypeScript/pull/51880/files?show-viewed-files=true&file-filters%5B%5D=#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R2320

// before, because `SymbolLinks` is a functionnew(SymbolLinksasany)()// afternewSymbolLinks()

I wonder how many more of those kinds of things we have that could be switched.

(Those links don't seem to work, but the example is enough to convince me, personally.)

They don't work because checker isn't expanded by default, you have to expand it manually.

I didn’t realize we were using a constructor function before. The crux of my question is really, is there a reason why it’s notfunction createSymbolLinks(): SymbolLinks { return {}; }, and do we know what the difference in performance characteristics between the two is.

Does using a class mean instances of SymbolLinks will share the same hidden class even if different properties are attached in different orders?

No, whether you are using aclass orfunction has no bearing at the moment because the actual emit fromesbuild is a class with no fields. Native classes with native fieldswould ensure all properties are defined ahead of time, which would help but we can't leverage that currently.

If not, how bad is the memory impact of initializing all the possible properties toundefined? (I assume awful because there are so many.)

You're essentially adding the space for a heap pointer (roughly 8 bytes) for each property, per object. The best way to reduce that cost is to cut back on what we actually need to store on the object, either through the introduction of bitflags to condensebooleans, putting lesser used properties in their own objects, or not storing anything that can be trivially recomputed.

Did you test the class implementation against an object literal implementation?

Not for this specifically, but in general I have yes. There's no real difference in storage, but object literals are far harder to isolate when looking at memory snapshots or v8 traces since they all haveObject as their constructor.

(roughly 8 bytes) for each property

This isn't entirely accurate. IIRC, every object in V8 has an initial structure that is fixed in size and can hold a small number of properties directly. Additional properties beyond that limit are stored elsewhere on the heap. This means every object allocation has a minimum size that accounts for some of the properties.

I didn’t realize we were using a constructor function before. The crux of my question is really, is there a reason why it’s notfunction createSymbolLinks(): SymbolLinks { return {}; }, and do we know what the difference in performance characteristics between the two is.

All object literals share the same constructor so they show up asObject in the debugger, in memory snapshots, and in the v8 trace logs, which make them impossible to differentiate from one another. We should really try to use object literals only for throw-away things like options bags for functions, or destructuring results. Using a class for objects with a longer lifetime is preferred, even if we're just using it as a tag, i.e.:

functioncreateFlowNode(){return{}asFlowNode;// bad for debugging/snapshots/tracing}// vsfunctioncreateFlowNode(){returnnewFlowNode()asFlowNode;// better for debugging/snapshots/tracing,// but pretty much the same as {} otherwise}// minimum needed to tag the object for diagnostic tooling, though it would be better// if the object has a stable set of properties we can pre-allocate:constFlowNode=classFlowNode{};

The only downside to this approach is that you end up with a unique starting "map" for each tag (since it points to a different constructor/prototype)

For example, there are 215 different V8 maps for Object here that I have no insight into without drilling into each one, vs the other constructors in this list: