[PERF] Investigate `@FastNative` and `@CriticalNative` usage and compiler optimization flags

[david-allison]

@FastNative and @CriticalNative could significantly improve performance

• https://source.android.com/docs/core/runtime/improvements#faster-native-methods
• https://nickb.website/blog/speeding-up-your-android-apps-native-calls

[dae]

Looks cool, but the savings are probably limited. Backend methods typically do a bunch of work at once to minimize IPC costs, so this would mainly help for legacy code that accesses the DB directly (if there is still any of that?)

[david-allison]

I don't feel that this is a priority currently. Things are already fast.

Once we have a little more capacity, or an interested developer, I'd want to measure differences in browser row rendering, which would determine whether we continue optimizing. Due to 120Hz rendering, we're potentially dropping frames in the browser

---

We have very few direct DB methods at this stage.

Off the top of my head, the areas we'd make savings would be:

• Browser row rendering
• Progress notifications (especially background media syncing)
• Seeing if we can save milliseconds on the critical path of the study screen

[dae]

Browser row rendering is definitely worth exploring as it's one of the most frequent calls. My gut tells me that it may not make an appreciable difference in this case (as while frequent, we're still only talking about ~100/sec). But my gut has been known to be wrong in the past. :-)

[mikehardy]

Been looking for a place to drop some ambient things I've noted in react-native's constant search for milliseconds and while this is not strictly related, I'm going to dump a little dog's dinner of performance notes from over there

They are all in the vein of "perhaps we can squeeze some nearly-free performance out of simple build tweaks", with the idea that Meta invests heaps of time in this for the framework it uses for it's billion-dollar apps:

1- context is - this the full string of build flags used to build react-native release mode as of early 2025

this one was looking at adding flto but apparently it was already in there, and specifically as thin whatever that means

https://github.com/facebook/react-native/pull/52488/files#r2195134576

LANGUAGE_COMPILE_FLAGS = -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D__BIONIC_NO_PAGE_SIZE_MACRO -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -O3 -DNDEBUG -flto=thin

2- context is - react-native has recently done a lot of testing, and is leaning heavily now on "go for speed vs space" optimizations. The speed turns out to be non-trivial and the space savings trivial, so they've moved philosophical position in that tension:

https://github.com/facebook/react-native/pull/50805/files

-              "-DCMAKE_BUILD_TYPE=MinSizeRel",
+              "-DCMAKE_BUILD_TYPE=Release",

3- context: some random flag being added into their build flag mix recently, apparently worth it if they're doing it:

https://github.com/facebook/react-native/pull/50581/files

        "-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=True",