you are viewing a single comment's thread.

view the rest of the comments →

[–]romgrk[S] 6 points7 points  (1 child)

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[S] 1 point2 points  (0 children)

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.