GeezerVison

I added this primarily to catch an unconditional cast to SymbolLinks from Symbol 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 to undefined? (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 to any at https://github.com/microsoft/TypeScript/pull/51880/files?show-viewed-files=true&file-filters%5B%5D=#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R2573 and https://github.com/microsoft/TypeScript/pull/51880/files?show-viewed-files=true&file-filters%5B%5D=#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R2320

// before, because `SymbolLinks` is a function
new (SymbolLinks as any)()

// after
new SymbolLinks()

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 not function 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 a class or function has no bearing at the moment because the actual emit from esbuild is a class with no fields. Native classes with native fields would 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 to undefined? (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 condense booleans, 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 have Object 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 not function 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 as Object 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.:

function createFlowNode() {
  return {} as FlowNode; // bad for debugging/snapshots/tracing
}

// vs

function createFlowNode() {
  return new FlowNode() as FlowNode; // 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:
const FlowNode = class FlowNode {};

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: