2023/2024 Performance Improvements

[coolsoftwaretyler]

@jamonholmgren put together a Twitter poll asking if folks would prefer for MST to:

1. Improve TypeScript types
2. Improve performance

Improving performance won with 48.6% of the vote.

The poll only had 72 participants, and 16.7% of them just voted to watch the results, but I think anyone reading through old issues and discussions could see that this is an often-requested improvement in our library over the years.

Jamon and I also asked our own coworkers - both of us work at companies that make heavy use of MST in production. The consensus there was also that performance is more impactful than TypeScript improvements.

All that to say, it seems like improving the performance of MST in the next year would be a huge boon to our downstream users, and we should consider using this feedback as guidance in our overall direction.

I am going to open a series of discussion posts about MST performance we can use to solicit more specific feedback. This is the first of them, and I'd like to use it to specifically discuss the big picture: do people agree that this should be a priority? If so, why? Do people disagree? If so, why?

I'd like to keep this discussion post open and pinned as a landing page where we can collect links to other discussions, issues, PRs, and milestones.

[coolsoftwaretyler]

I'm about to log off for the evening, but here's some things I think we should consider:

1. If we discuss performance, we should do more to benchmark and define performance and what it means to MST. There are some tests in packages/mobx-state-tree/__tests__/perf that seem to run some benchmarks, but I don't totally understand what they're measuring, and I have a feeling that we need more than that.
2. Once we have good definitions of what we mean by performance, and we can measure existing performance, we should determine some set of threshold for what we think "improvement" is. We will hopefully end up with measurements across multiple dimensions, and I think we should consider what measurements we want to improve, and by how much.
3. We should aggregate all of the open issues that are specifically about performance. Especially if they include reproduction steps and/or suggestions to fix the issue. It would be good to pay back the folks who took time to document their issues and give us breadcrumbs on how to improve MST overall.
4. I hear that MobX-Keystone made some performance gains over MST. We should reach out to them if we can, or look at what they've done and learn from it.
5. MobX-Quick-Tree has hopped on a call with me and Jamon before and they have a lot of experience benchmarking and improving MST performance. Again, we need to keep working with those folks and learning from them. I think they have clearly demonstrated there's a path forward to performance gains even without breaking changes.
6. Also, as we define, benchmark, and improve performance - I'd like to see more and better test coverage to be careful of breaking an existing APIs (documented or undocumented behavior).
7. Which brings me to my last thought: breaking changes - we should consider how much we are willing to break in an effort to get performance improvements. I don't want to start here, and my hope is we can deliver performance improvements without a major version change. If we do that, we can deliver a ton of value to the community for minimal effort on their part. But it seems reasonable to expect that we might hit a performance ceiling (or performance floor?) required by maintaining the existing API of MST.

This was a long comment! I'm on a road trip and sort of writing train of thought, capturing ideas that were bouncing around in my head on the long drive. Hopefully other folks can take these ideas and run with them. Even if things start slowly (pun intended), I'm excited to explore what we can do here!

[chakrihacker]

Nice Writeup

[vonovak]

Thanks for this! In context of React Native, it might be interesting to benchmark / document how and if turning off Proxies helps with perf on the Hermes engine. I remember that Proxies were added to Hermes somewhat reluctantly also because they are bad for performance. Worth noting that there might be difference between Hermes and browser engines that can optimize at runtime.

[coolsoftwaretyler]

One way to begin measuring and benchmarking performance is to reproduce specific scenarios that actual users run into with MST. Here's a discussion post soliciting these scenarios: #2096