[HOLD for payment 2024-04-15] [Tracking] Metric - App Startup (Performance audit by Callstack)

[hurali97]

Description:

As a part of the #33070, the issue tracks and summarises phases for App Startup Metric. Here we will share the Measurements, Analysis and Implementation details as we progress through the Audit.

[melvin-bot]

Triggered auto assignment to @trjExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[hurali97]

Metric: App Startup
Phase: Measurement
Commit hash: f268c39
Commit hash with setup for audit: 452595f

Flow:

1. Open the app
2. Splash will be hidden after a few secs
3. Login to the app
4. Then wait for the data to show
5. Close the app and force stop it from the settings
6. Open the app again
7. Splash will be hidden after a long period
8. Data will be visible when the splash hides

For each subsequent measurement, steps 1-3 are not followed. Which means we loop over from step 5-8 for the measurement cycle.

This way we get the app startup of the usual flow that a user faces after the fresh install, uses the app for a while and closes it. And then each time he'll launch the app he follows the same flow as we are following here.

Markers:

There are already a bunch of markers in place in the Performance class but it's missing some other valuable markers that might come in handy when analysing the measurements. Also, the ending TTI marker wasn't placed precisely as it was being executed even before the splash was hidden. Ideally, we want to end the marker when the splash hides.

• We are only interested in the following markers:

  • nativeLaunch
  • nativeLaunchEnd_To_appCreationStart
  • appCreation
  • appCreationEnd_To_contentAppeared
  • contentAppeared_To_screenTTI

  And

  • TTI

• If we combine the markers without TTI we should get the value equivalent to TTI. This gives us a chance to analyse each phase in app startup and pin point the root cause for potential fixes.

Measurements:

---

We see that TTI takes about 50 seconds, which means for that period the user can't interact with the app. This reflects a use case for a really heavy account and can be considered as a worst case scenario. Each improvement considering this scenario will benefit other users as well.

[mountiny]

Thanks!

[trjExpensify]

@mountiny what am I doing with this bud?

[mountiny]

Nothing for now thanks! Wrong labels been used

[hurali97]

Analysis: Replace localeCompare with Intl.Collator

Details

We start off by analysing the trace recorded with the help of [hermes release profiler](https://github.com/margelo/react-native-release-profiler) in a release build on a really heavy account, which has more than 15k reports.

The measurements we had from the previous phase amounts to 48.5 seconds for TTI.

While analysing the hermes profile trace we realised that the function getOrderedReportIDs takes about 50% of the TTI. Diving further shows us that there is a sorting mechanism in getOrderedReportIDs function which calls String.localeCompare() method, which is the root cause of bottleneck in getOrderedReportIDs function.

We have sorting on 4 arrays in getOrderedReportIDs function. An example of one sorting is as follows:

draftReports.sort((a, b) => (a?.displayName && b?.displayName ? a.displayName.toLowerCase().localeCompare(b.displayName.toLowerCase()) : 0));

Exploring the slowness in String.localeCompare() method, we looked for resources in Hermes itself. There we found this issue which explains that why it's pretty slow, especially on large data. Based on the suggestions, the best shot is to use Intl.Collator and create it's instance one time then re-use that instance to compare locales.

Below is how this would look like in practice:

let currentLocale = 'en';
Onyx.connect({
    key: ONYXKEYS.NVP_PREFERRED_LOCALE,
    callback: (locale) => {
        if (!locale) {
            return;
        }

        currentLocale = locale;
    },
});

const collator = new Intl.Collator(currentLocale);

const localeCompare = (str1, str2) {
  return collator.compare(str1.toLowerCase(), str2.toLowerCase());
}

function getOrderedReportIDs (...args) {

...

draftReports.sort((a, b) => (a?.displayName && b?.displayName ? localeCompare(str1, str2) : 0));

...

}

We can further improve this by removing the str.toLowerCase() by adding sensitivity options to Intl.Collator:

const collator = new Intl.Collator(currentLocale, {usage: 'sort', sensitivity: 'base'});
const localeCompare = (str1, str2) {
  return collator.compare(str1, str2);
}

With these improvements, we recorded the hermes profile trace again and the TTI is reduced drastically by ~50% 🚀

---

This patch is also tested in other metrics like Send A Message, Report Screen Load Time and the results are jaw-dropping 😮 For eg, in Send A Message result dropped from 27 seconds to 5 seconds of the whole execution time 👏

[hurali97]

Analysis: Replace Intl.Collator with basic comparison

Details

Now we know that `Intl.Collator` brings in remarkable performance improvements but given our huge data it still takes some noticeable amount of time. For example, we still see about ~1.7 seconds spent in sorting for `getOrderedReportIDs`.

We can improve this further by using the basic comparison, only downside is that it might or might not play well with non-english locales. But since we are only comparing on displayName which will probably only be in English. Otherwise, we can do a regression test with other locales supported by Expensify.

Following is how it will look in practice:

 const compareLocale = (str1: string, str2 : string) => {
     if (str1 === str2) {
         return 0;
     }

     if (str1 < str2) {
         return -1;
     }

     return 1;
 }

const localeCompare = (str1: string, str2 : string) => {
    return compareLocal(str1.toLowerCase(), str2.toLowerCase());
};

That's all we need to do based on the improvements from previous analysis. This speeds things up and bring us about 2-3 seconds of reduction in the App Startup Time.