Performance degradation with large objects and arrays about react-native-reanimated

[chrfalch]

I think the main issue comes from the fact that Skia implemented arrays without copying values - in Reanimated arrays are copied when transformed back and forth. The relevant code is found here:

react-native-reanimated/Common/cpp/SharedItems/Shareables.cpp

Lines 171 to 175 in 469d708

	jsi::Value ShareableArray::toJSValue(jsi::Runtime &rt) {
	auto size = data_.size();
	auto ary = jsi::Array(rt, size);
	for (size_t i = 0; i < size; i++) {
	ary.setValueAtIndex(rt, i, data_[i]->getJSValue(rt));

[piaskowyk]

Hey! 👋 Thanks for the report and the prepared benchmarks! 😍 We will definitely take a look at them and try to make it faster!

[tomekzaw]

@marcocaldera I've just noticed that you're using Reanimated 3.6.1 – is this issue reproducible also on the latest version (currently 3.8.1)? I'm asking because in 3.7.0 we've released a huge improvement (#4300) that can positively affect the performance when shared values are updated frequently on the UI thread.

[tomekzaw]

@ranaavneet I'm afraid it all depends on the benchmark; as far as I remember in our initial benchmarks held by @piaskowyk we got 20% performance improvement, but obviously we can't predict all usages. Thanks for referencing #5816, we'll keep that in mind.

[marcocaldera]

@marcocaldera I've just noticed that you're using Reanimated 3.6.1 – is this issue reproducible also on the latest version (currently 3.8.1)? I'm asking because in 3.7.0 we've released a huge improvement (#4300) that can positively affect the performance when shared values are updated frequently on the UI thread.

Interesting. I run a set of tests based on two new things:

• reanimated 3.8.1
• using an array buffer

Debug mode:
https://github.com/software-mansion/react-native-reanimated/assets/93535783/e077d26b-81f3-4fb8-a0bc-d90cac63e7e4

UI thread runs now at 60 FPS everywhere. JS thread seems to suffer more on certain occasions.

Flashlight report on Samsung A51:

In the flashlight report maybe it's not super evident but the reanimated performance in terms of FPS is around 55 now (a nice improvement).

As you can see using ArrayBuffer leads to great performance.

[tomekzaw]

@marcocaldera That's right, ArrayBuffer is a powerful data structure. Glad we added support for it in #5223 😄

We were also considering adding support for SharedArrayBuffer so that you can modify it safely from both runtimes (RN and UI), do you think it would be useful?

I suspect that the current approach is to use .modify but under the hood it calls runOnUI so the update from RN runtime is asynchronous. Instead, we could update the buffer directly (with proper synchronization).

[chrfalch]

@chrfalch Could you please share more details on that? Assuming that accessing these arrays doesn't require any additional blocking synchronization, how is that possible?

@tomekzaw: So sorry for the delay in getting back on this one. This feature was removed from Skia as previously stated, but the idea is still valid. Here is (from the top of my head what I did).

The array wrapper will be the owner of the array data, so when constructed it converts all JSI values to C++ values to be able to marshall back and forth on different UI runtimes. This gives us the possibility of keeping memory references to the same memory locations (as you also describe) throughout the lifetime of the array wrapper.

In addition we look at reading and writing as two very different operations - where reading is thread safe and available without locking - and writing is protected by a lock in the wrapper.

This way we get the benefit of not copying the data when moving between runtimes, and also the speed of reading without locking - and finally the necessary protection of write operations.

Hope this makes sense :)

[tomekzaw]

in Reanimated arrays are copied when transformed back and forth

That's correct, when you copy any value from let's say RN to UI runtime, they are first serialized from JS values in source runtime into runtime-agnostic C++ data structures (so-called "shareables") and re-created on the target runtime as JS values.

Skia implemented arrays without copying values

@chrfalch Could you please share more details on that? Assuming that accessing these arrays doesn't require any additional blocking synchronization, how is that possible?

[ranaavneet]

@marcocaldera I've just noticed that you're using Reanimated 3.6.1 – is this issue reproducible also on the latest version (currently 3.8.1)? I'm asking because in 3.7.0 we've released a huge improvement (#4300) that can positively affect the performance when shared values are updated frequently on the UI thread.

Hey @tomekzaw isnt this conflicting the issue reported in #5816. This benchmark in this issue states the opposite of #4300