Samuel
@samuel.fm
this doubles the framerate when scrolling on low-end android. wtf Reanimated 😅
skywatch@skywatch.bsky.social· 11 Nov 2024
New PR: Reduce Reanimated serialization traffic (#6219)
Reduce Reanimated serialization traffic by gaearon · Pull Request #6219 · bluesky-social/social-app
This was a major WTF moment for me and I'm still not sure to what extent this is actually useful. However, the Android GPU profiler seems to be happy about this change. There is some informatio...
github.com
10 7 232
Tom Sherman
I'm interested in why the before and after photos seem to be taken on a cobbled street using the illumination of street lamps
1 10
Oliver Kwast
I looked at the diff, but I’m not entirely sure I get it — why does this change improve the framerate so much?
1 3
Samuel
Reanimated is basically a babel plugin that converts your code to multi-threaded concurrent JS. This means that when you have a worklet, it has to serialise the closure to the UI thread which can be really slow when you’re closing over more than you realise. Although in this case I think it’s a bug
1 10
Krzysztof Magiera
This doesn't have to do anything to do with serialization. Worklets are only "serialized" when created, so in this instance only when headerMode changes, which I assume isn't frequent. Serialization only happens once for a given object and then it is cached, so withSpring is only serialized once
1 6
Krzysztof Magiera
What this change does it is simply skips calling `withSpring(0, {})` in favor of executing it only once when mutable is created and caching that value. withSpring returns an animation object which gets cached in a mutable in this case.
1 6
Krzysztof Magiera
You should be able to verify that by leaving reference to withSpring inside that worklet but just not calling it. In that case this should not degrade performance. I believe it is simply the runtime cost of withSpring call that needs to be optimized
2 10
dan
in my testing it was definitely *referencing* that caused issues even if the code was not being called (i couldn’t believe it at first so i verified a dozen times). it was a late night though so it may be worth verifying again
1 7
dan
in fact, even referencing that `setMode` function (which closes over withSpring) without ever calling it was enough to cause the perf degradation. this was slow: var x = setMode this was fast: // var x = setMode
1 9
Krzysztof Magiera
what would trigger this behavior then? I understand that now there's some scroll event that triggers the worklet that references the method. But when that happens, there's no serialization – it only happens when the worklet is defined which likely runs once in that component lifetime
1 1 3
Krzysztof Magiera
you shouldn't also need the makeMutable call there. Just assign `const V0 = withSpring(0, {})` and use it as `V0` rather than `V0.value`
1 4
Krzysztof Magiera
I think that this weird behavior could be attributed to this cancelAnimation bug that got fixed recently: github.com/software-man... – this bug may result in unpredictable ui thread stutters. Apparently this change isn't yet in public release but since fix is JS-only you can try to patch it
1 2
1 more reply
richard
Does this problem go away with new arch or are these worklet things needing this serialization regardless
1 2
Samuel
no, Reanimated is a library for JS-thread<->UI-thread stuff rather than JS-code<->native code which is what new arch is all about
2
richard
I haven’t used it personally, but there are requests to. We have a custom platform, so it’s a bit different. Ty for the reply.
1 2
Samuel
oh wait playstation?? that's awesome, I didn't know that's RN! yeah Reanimated is great, extremely powerful (but easy to mess up sometimes)
1 1
Josh Holme 📎
Sam please let us load new posts above our spot on our timeline so we don’t have to jump to the top and then find our way back to the bottom