Checking is slow in project consuming xstate types

[amcasey]

The original project is here: https://github.com/AlCalzone/node-zwave-js
The actual owner is @AlCalzone

1. Clone https://github.com/amcasey/ZwavePerfRepro
2. npm ci
3. tsc -p .

The portion of the code below // ACASEY boils down to a single function call that takes the vast majority of the checking time. The portion of the code above is enough scaffolding to make it compile.

I've framed the problem in terms of tsc because it's easier to investigate, but the editor experience is also terrible.

[amcasey]

At a high level, the issue is that the many types in the 600-line object literal depend on the parameter type of the function to which it is passed, which depends on the type of the argument (it's not quite a cycle, but it's close).

[amcasey]

Looks like it can be reduced quite a bit. You can replace the whole createSendThreadMachine function with this and the performance is basically the same.

const _on: TransitionsConfig<SendThreadContext, SendThreadEvent> = {
    add: [
        {
            cond: "isPreTransmitHandshakeForCurrentTransaction",
            actions: [
                assign({
                    preTransmitHandshakeTransaction: (_, evt) =>
                        evt.transaction,
                }),
                raise("preTransmitHandshake"),
            ],
        },
    ],
};

[amcasey]

I've pushed a Simplified branch with a greatly reduced repro. It takes about half as long as the full repro, but a lot of that came out of program time. The Type and Instantiation counts are still very high (and depend entirely on the declaration of _on, mentioned above).

[amcasey]

I'm seeing a slow comparison (roughly half of check time) between two instantiations of State.

Edit: specifically, it's a variance check of the first type parameter of State (i.e. with marker types substituted for the first type parameter).

Edit 2: If I hard code the variances for that type as [], the problem goes away (fast checking, few types, few instantiations).

[amcasey]

I've updated the Simplified branch with this further reduced repro:

import { ActionObject, AssignAction, EventObject } from "xstate";

interface DummyContext {
}

interface Event1 {
    type: "evt1";
}

interface Event2 {
    type: "evt2";
}

type Action<TContext, TEvent extends EventObject> =
    | ActionObject<TContext, TEvent>
    | AssignAction<TContext, TEvent>; // NB: extends ActionObject<TContext, TEvent>

declare const action1: AssignAction<DummyContext, Event1>;
const action2: Action<DummyContext, Event1 | Event2> = action1;

(That's it! You could copy-paste, but cloning conveniently pulls down package-lock.json, etc.)

[amcasey]

@davidkpiano It seems strange that Action contains both AssignAction and its base type ActionObject. Was it intentional and, if so, what was the goal? I'm pretty sure it's contributing to the perf issues some consumers are seeing (because the compiler has to compare two very similar types).

p.s. Please let me know if you'd rather have an issue in the xstate repo - I started here to spare you the clutter.

[davidkpiano]

@amcasey I believe that was part of the effort to get inference right for something like this:

{
  actions: assign({/* ... */})
}

Where we wanted that to "just work" without having to specify generic types for assign every time, e.g.,:

{
  actions: assign<SomeContext, SomeEvent>({/* ... */})
}

Hence actions being typed as:

type Action =
  | ...
  | AssignAction<...>
  | ...

For proper inference. I will look into simplifying that type.

[amcasey]

@davidkpiano I'm not super-familiar with xstate, but the customer repro I'm working with produces the same completion items in that position if I delete either AssignAction or ActionObject (just much more quickly). It looks like they're just based on the context type argument, which should be inferred the same, regardless of which is removed.

[amcasey]

I believe @davidkpiano's change resolved this issue. Thanks!

p.s. I'm still investigating how we could have made the problem easier to identify.