Samuel
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
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
@samuel.fm
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
Krzysztof Magiera
finally, you can remove that cancelAnimation call entirely. The next line where you assign new animation to shared value will also cancel the previously running animation
1 4
dan
i *do* understand that my conclusion looks shady. but what i was observing is definitely what i’m describing — that merely commenting out a *reference* to a method that closes over withSpring, with *all* calls to it commented out, made the difference. so it’s not explainable by cancelAnimation
1 4
1 more reply