[HOLD for payment 2024-07-10] [HOLD for payment 2024-07-02] [HOLD for payment 2024-06-28] [HOLD for payment 2024-06-28] MEDIUM: Enable Function Symbolication for Detailed Performance Tracing

[muttmuure]

Problem

Without symbols in our profile traces we can only guess which functions took so much time, based on the bottom-up stack (and try to manually map the amount of loops & internals to what we have in code).

Solution

Properly symbolicate the data in the performance profile feature into human-readable function names, line numbers, and file names so our team can identify the cause of slows in app.

Issue Owner

Current Issue Owner: @greg-schroeder

[melvin-bot]

Triggered auto assignment to @grgia (AutoAssignerNewDotQuality)

[muttmuure]

@grgia I think this is likely one that an agency contributor will need to take the lead on.

@Szymon20000 @adhorodyski can you give us a path forward on achieving symbolication in our current profile tracing?

[adhorodyski]

@Szymon20000 as far as I remember the ones we used to receive with different bug reports were already symbolicated correctly.

Do you think anything could have changed in this regard lately for the react-native-release-profiler?

Here's one from 1 day ago that I couldn't symbolicate myself against latest main (same on @hurali97's end). We don't know (yet) the git tag for the build so it's not possible to match it against a source map file manually either.
Profile_trace_for_1.4.81-9.cpuprofile

And that's the same one after matching it against this branch:

[hannojg]

Hey, Hanno from Margelo here. I will look into checking why we have no source maps using rn-release-profiler in expensify. Feel free to assign to me! 😊

[hannojg]

The traces we record on the device are unsymbolicated. We need a way to symbolicate them. The flow would be:

1. A user shares a profile trace
2. A developer receives the trace
3. The developer runs a script to symbolicate it

We already have a script for symbolication in place. The issue however is that the profile the user created is specific to an app version. And the script only symbolicates for the current commit we are on.
Additionally, switching versions as developer just to symbolicate the trace is quite the overhead (as a new release build needs to be created).

So a better solution would be to:

1. Add a GitHub action that runs when we create a new release version and uploads it as artefact to the GitHub action workflow run (also for the staging app versions).
2. Update our script to:
   1. Get the app version from the file name of the trace
   2. Download the artefact from the GitHub action runs for that version

I can help with implementing that.

[grgia]

@hannojg, thanks for looking into this. Shall I assign you this one?

[hannojg]

Yes please, I'd go ahead and create two PRs, that will:

1. Upload a source map when we make a new release version
2. Update our scripts (and documentation) for symbolicating a trace using the uploaded source maps

[hannojg]

Update for step 1 uploading the source maps:

• I found that we already upload source maps, support was added in
  • Capture ios|android sourcemaps as deploy job artifacts #9641
• However, its broken and not uploading for android and iOS
• Additionally it would be nice if we can link the assets with the tag (have to see if that works)
  • Update: doesn't work 😅

So I will fix the existing system first