Does the React Native Perf Monitor distort the bridge bottleneck it is measuring?

Measuring before optimizing is standard advice, but in React Native the measurement itself is the hard part when the suspected bottleneck is the bridge.

Assume a recent release (0.70+) where Hermes is the default engine. Hermes ships a sampling profiler for JavaScript execution, yet there is no built-in, fine-grained API for timing individual native module round trips. Development builds add validation and warning checks, and the in-app Perf Monitor plus an attached debugger impose their own overhead, so dev-mode numbers may not reflect release behavior. Native timestamps such as System.nanoTime on Android or mach_absolute_time on iOS around a module call are one workaround, but that instrumentation is per-project and its own cost is rarely quantified.

That leaves an unresolved decision: when frequent native module calls make a screen feel slow, which measurement should justify the optimization effort, and should that effort target bridge traffic or a migration to the New Architecture (default for new projects since 0.76)?

• Which approach best approximates production bridge latency: native-side timestamps around module calls, or the Hermes sampling profiler combined with release-build testing?
• How much overhead do the Perf Monitor and attached debuggers add, and at what call frequency do their readings become misleading?
• Is there an accepted round-trip threshold that would justify migrating to TurboModules instead of batching or caching calls?