react-native-performance icon indicating copy to clipboard operation
react-native-performance copied to clipboard

Published 20 hours ago • verified publisher icon oblador

High numbers on iOS?

Open pfulop opened this issue 2 years ago • 2 comments

We are currently using this library to determine which part of the app is currently the slowest to load. One thing we noticed are high numbers for measuring nativeLaunchEnd relative to nativeLaunchStart on ios. For instance, we see 340756159ms which translated to almost 4 days. This would mean the app is taking 4 days to start. Are there some cases where this can happen and how to prevent them? This is currently polluting our measurements.

pfulop avatar Mar 15 '22 13:03 pfulop

Are you seeing this in development or real user monitoring? If the latter is it possible that it's related to users backgrounding the app during startup?

oblador avatar Mar 15 '22 15:03 oblador

This is in production.

If the latter is it possible that it's related to users backgrounding the app during startup?

I would not expect days in that case but max hours. I would expect ios clearing that process within a day.

pfulop avatar Mar 15 '22 15:03 pfulop

Was seeing this too in RN 0.68.2 Which I believe was fixed in https://github.com/facebook/react-native/pull/33983 and is not reproducible in 0.68.9 anymore.

The issue I believe is in difference of "now" primitives used by react-native-performance and by RN runtime itself. RNPerformanceGetTimestamp uses std::chrono::steady_clock::now() while RN used std::chrono::system_clock::now().

gavrix avatar Dec 21 '22 17:12 gavrix

Native launch indeed reporting very high numbers which likely the result of iOS pre-warming.

On iOS we can no longer assume that process creation time is the time when user launched the app. Process can be created way ahead of time (pre-warming) before user launches the app, at which point main entry point starts executing. More on this topic can be found here.

This is legit issue @oblador. I think the way to resolve this is to break up native_launch into native_load and native_initialization:

  • native_load: interval between process creation and code initialization (__attribute__((constructor)) attribute)
  • native_initialization: interval between calls to main (or appDidFinishLaunchingWithOptions) and RN module initialization (where we currently calculate sNativeLaunchEnd)

Not sure how this would translate to android though. I guess, we can also assume native_launch to be a sum of those two and keep things simple.

gavrix avatar Jan 06 '23 18:01 gavrix

Closing this as it should have been fixed in 5.0.0, please open a new issue if it persists.

oblador avatar Oct 12 '23 10:10 oblador