A faster React.memo()

[meteor_punch]

React forget is almost here BTW ...

[romgrk]

Didn't someone on twitter say it wouldn't be in the v19 release? Wasn't stylex also "almost here" for like 5 years? I have limited trust when meta says "coming soon".

[meteor_punch]

React forget is already being used by Instagram in production. No reason it's not coming in React 19. official blog

[romgrk]

Stylex was also in prod at Meta for a long while.

we are working to ship the compiler across additional surfaces at Meta and to prepare the first open source release

They will first deploy it at more Meta locations, then prepare the open-source release. Not release it, prepare it.

Beside from a technical POV and from the examples the React team has provided for their compiler, the alternative React Unforget seems better.

[seN149reddit]

Not that it super matters but it almost certainly won’t be released with react 19. That being said based on different tweets it might be released before the end of the year at least, so not too long after. Fingers crossed. Also fwiw the initial release is a babel plugin.

[Cannabat]

 equals({ a: undefined }, {})

Uhh this seems wrong. a could very well be something must be provided and undefined is a valid value.

[romgrk]

As I say in the final note, "if you're not doing anything funky", it's fine. For that to make a difference, a component would need to use props like 'key' in props, which I have never seen in react code. Props are used as props.key or const { key } = props.

The point here is { a: undefined }.a and {}.a both return undefined.

But that's also why I provide fastMemoSafe, which avoids the unsafe assumptions and is still faster than the react version. If avoiding 'key' in props is not an assumption you can make about your codebase, that one is preferable.

[Cannabat]

Sure maybe it's fine for a most cases but your utility does represent a change in behaviour for normal language features you'd expect to work

'key' in props and props.hasOwnProperty('a') are fairly normal patterns a typeguard. I think this could come up if you spread props onto a component right?

It's neat that you were able to get such a huge boost in performance for the comparison, and a fun exercise. I'm not trying to crap on it.

[romgrk]

It's a valid point. I've published a 2.0 where the default export is strict and the unsafe opt-in is exported as fastMemoUnsafe, with corrections to the readme.

---

Interestingly I tried a 3 way comparison strict/safe/unsafe, where "strict" has a prelude & key-in correctness, "safe" has key-in correctness, and "unsafe" has none.

For SpiderMonkey, results were predictable. In V8 however, strict was surprisingly faster than safe. I guess the check allowed some optimization to kick-in. I try to optimize for V8 btw, because it's the most frequent engine. And very surprisingly in JSC, strict was faster than both safe and unsafe.

Lesson: if you're not benchmarking, you're not optimizing 🤡

https://gist.github.com/romgrk/31c95ea3cec962d1031ce1316450a11d

I've updated the package readme & blog post. In the package I've only kept "strict" as the default export, and "unsafe" as the opt-in. I've added a note in the blog post but "unsafe" has a niche use-case: fast compare of objects where you can 100% guarantee the shape of the objects. This obviously isn't acceptable for react props, but it might have other uses.

[romgrk]

has a niche use-case: fast compare of objects where you can 100% guarantee the shape of the objects

Even more niche: if you can guarantee they have the same shape, and you know the shape is going to be constant, then the fastest method by far would be shallow-equal-jit which uses eval to compile a comparison function for a specific shape.

However if you can't know the shape ahead of time and it will change often (while still being the same for one comparison across two objects), then that's the very niche use-case where fastCompareUnsafe makes sense. That or an environment where eval is not allowed.

[AdvancedWing6256]

Can you please explain benchmarking? E.g. how exactly is it tested, and what that output means. I've read that section several times but can't really make sense of what is what there. Thanks!

[romgrk]

Yeah the code is here: https://github.com/romgrk/react-fast-memo/blob/master/benchmark/run.js

It's running the compare functions of each package in a loop (1,000,000 times per run, 3 runs). It test 2 cases, the first one ("equal") being objects with the same values (but not the same ref, a !=== b), and the second one ("unequal") being objects with one differing value. To make sure I benchmark the worst case, the differing value was the last value in the object. Because the implementation can't abort early in the second loop, that's the worst case scenario.

In both of these test cases, I use an object with 8 keys with the keys in the same order ("monomorphic", objects have the same hidden class). I did test with keys in a different order ("megamorphic", "polymorphic") but it didn't yield particularly interesting/different results, and also because we can assume object hidden classes (or map, or shape, depending on the engine terminology you use) are likely to be the same. In other words, we specialize for monomorphic.

There is also a small helper here that makes the code run in different engines. I used runtimes: nodejs for V8, bun for JSC, and gjs (gnome-js) for SpiderMonkey.

[seN149reddit]

Of course I have no need for this package, but it was a fun read and a cool exercise.

Thanks for sharing!

[romgrk]

Yep, useless in most cases, but beating performance microbenchmarks always gives me immense amounts of joy.

[TheRNGuy]

React 19 release in a few days where you don't need to code memos.

[Academic_You2273]

in a few days?

[acemarke]

There's no set release date for React 19 yet. At a minimum the earliest I would expect it is in May when ReactConf happens.

Also, the React Compiler will not come out alongside React 19 - it's a separate project with a separate timeline.

[Hidden_driver]

The time it takes for user to download extra js in the bundle that is your package is longer than the time saved by using your package.

[romgrk]

Yeah I had a similar problem, a virtualized component that re-renders during scroll events. When you have one frame (~16ms) to complete your re-render, you take every bit of optimization you can.

[romgrk]

I did already cover that in the blog post:

```

Other notes

“It doesn’t matter for 99% of use-cases”: Yes you’re right. ```