General performance improvement ideas

[MarshallOfSound]

I have a set of general performance improvements to zustand, looks like PR creation is currently disabled (I assume due to GitHub spam or something)

Can you add my user to the allowlist? (Check my history, maintain a bunch of OSS projects, just trying to make things better 🥳)

I can also just upload patchsets / link to the branches on my forks if that works

cc @dai-shi

[dai-shi]

My gut feeling is we don't do general performance improvements, but I'm not sure.
Please share your ideas. In the end, a patch will be helpful, but it feels like it's easier to discuss with pseudo code first.

[MarshallOfSound]

@dai-shi These aren't API / surface changes, rather very small tweaks in the JS to send it down slightly more optimized paths in most JS engines. Zustand is the core state layer in a bunch of real-time / high frequency applications so saving a few ms on every state update is a big win. I've laid out the perf wins below:

Using spread instead of Object.assign, follows a hot path and reduces allocations on state updates

Improve the performance of shallow, the Object.entries codepath allocated a surprising amount of stuff on the heap and isn't very fast. This implements per-object-type optimized shallow helpers that allocate less and get to the answer faster

Avoid a useCallback that serves no performance purpose, this is the smallest of the three, but you don't actually need a stable getServerSnapshot reference for react, it just doesn't care 😅 So this saves some allocations and react fiber cost

[dai-shi]

Thanks for suggestions!

Using spread instead of Object.assign

Yes, I have considered it. I guess someone suggested it before too. I will consider this when we do major bump.

Improve the performance of shallow

Our goal with shallow isn't such performance. We prefer small implementation. If you or someone is interested, they can create a third-party library, such as performant-shallow.

Avoid a useCallback that serves no performance purpose

This is a nice catch. I wasn't aware of it. I think it's worth a patch release.

[MarshallOfSound]

Yes, I have considered it. I guess someone suggested it before too. I will consider this when we do major bump.

Is the major bump for browser support reasons?

Our goal with shallow isn't such performance. We prefer small implementation. If you or someone is interested, they can create a third-party library, such as performant-shallow.

Interesting and good to know, we'll lint-out the built in shallow impl and roll our own. Every little bit counts 😄

ty for the back and forth, if any more hotspots surface from zustand I'll bring them here for you to take a look 🙇

[dai-shi]

Yeah, as I remember, there was a subtle reason to prefer Object.assign, maybe for old browsers, which might not be valid anyways. I'll plan a major bump in the near future.

If I were to care performance, I'd use use-case-specific shallow function:

useShallow((s) => ({ x: s.x, y: s.y }), (a, b) => a.x === b.x && a.y === b.y)

[dai-shi]

#3563 is open.

Would you change the title of this discussion please? Something like, general performance improvement ideas.

[MarshallOfSound]

Done 👍