Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resolveStop is slow for large systems with unpredictable/random ids #4990

Open
ivankoleda opened this issue Jul 18, 2024 · 0 comments
Open

Comments

@ivankoleda
Copy link

XState version

XState version 5

Description

Stopping a system with lots of children with non-sequential/unpredicatable ids is slow.

Consider a following system

  • root
    • child 0 with id: uuid()
    • child 1 with id: uuid()
    • child 2 with id: uuid()
      ....
    • child 1000 with id: uuid()

Starting and stopping such a systems takes way more time than a system with predictable ids like 0, 1, 2...

It probably comes down to this line.

delete children[resolvedActorRef.id];

My guess having unpredictable object keys forces V8 to use less efficient internal structures for object representation.
Maybe using a Map internally can solve an issue. Although, exposing it externally would be a breaking change.

Expected result

If we provide predictable id in spawnChild, starting and stopping the system is fast.

for (let i = 0; i < 1_000; i++) {
  enqueue.spawnChild('child', {
    id: String(i),
  });
}
no_id_provided_in_spawn.mov
Screenshot 2024-07-18 at 22 10 50

Actual result

If we provide a random id, starting and stopping the system takes about 1 second on M3 mac without CPU slowdown.

for (let i = 0; i < 1_000; i++) {
  enqueue.spawnChild('child', {
    id: self.crypto.randomUUID(),
  });
}
uuid_provided_in_spawn.mov
Screenshot 2024-07-18 at 21 38 14

Reproduction

https://stackblitz.com/edit/vitejs-vite-y3j896?file=src%2FApp.jsx

Additional context

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants