Add hermes-specific support for the trace event format

[zacharyfmarion]

Profiles that are transformed into the hermes trace event format are guaranteed to have specific arguments that supply metadata that is useful for debugging - namely the filename, line + col number that the function call originated from, with sourcemaps applied. This PR adds specific support for this information to the trace event importer. This means that we can have the Frame name be just the name of the function, since we know all the information we want to be displayed in the UI is captured in the frame info, which makes the traces cleaner to look at.

Before	After

[coveralls]

coverage: 43.517% (+0.1%) from 43.39%
when pulling a8aabb2 on zacharyfmarion:zac/hermes-specfic-changes
into 88f4fe6 on jlfwong:main.

[zacharyfmarion]

Based on the spec this is not a required field for some event types, so marked it as optional. Happy to change back if this was intentional

[jlfwong]

Seems fine

[jlfwong]

Cool! High level looks good. A few minor requests inline, and then more generally please change all of the isHermesProfile arguments to be enum args instead of an ExporterSource with current values of UNKNOWN or HERMES. That way this will extend well if we want to specialize for other trace events types in the future, and also makes call-sites more self-documenting

[jlfwong]

As much as possible, I like to use enums rather than bare boolean arguments because it makes it clearer what's going on at the call-site. The true here isn't self documenting, but if this was e.g. return eventListToProfileGroup(rawProfile, ExportSource.HERMES) it would be really clear

[zacharyfmarion]

makes sense - generally I just make any function that takes in more than one obvious parameter take in an object so the meaning of every param is clear at the callsite, but I saw that it isn't a pattern in the codebase. Using an enum is super readable, will do that

[jlfwong]

For the sake of hermes profile import speed, it's IMO fine to just check the first event. Otherwise this seems like it might be needlessly slow.

[jlfwong]

Browsers probably optimize this anyway, but just for sanity, let's move this array outside of the call-stack. This seems like it would fit well as a constant directly below HermesTraceEventArgs as heremesTraceEventRequiredProperties

[zacharyfmarion]

@jlfwong thanks for the feedback, pushed up some fixes!

[jlfwong]

[0]?.args please!

[jlfwong]

Nevermind, this is guarded in isTraceEventList

[jlfwong]

Amazing!

If you write a markdown description (just in a comment here is fine) for React Native profiling, then I'll copy that into the wiki and update the README to link to it to indicate there's specific support for React Native via Hermes.

Here's an example of such a page: https://github.com/jlfwong/speedscope/wiki/Importing-from-pprof-(go)

[zacharyfmarion]

Importing from Hermes

Hermes is a javascript engine developed by facebook for use in react-native applications. For the most up-to-date instructions on how to take a profile, see Profiling with Hermes.

Profiling in Development Mode

To record a sampling profiler from the Dev Menu:

1. Navigate to your running Metro server terminal.
2. Press d to open the Dev Menu.
3. Select Enable Sampling Profiler.

5. Execute your JavaScript by in your app (press buttons, etc.)
6. Open the Dev Menu by pressing d again.
7. Select Enable Sampling Profiler again (this is currently a bug and might correctly say disable in the future) to stop recording and save the sampling profiler.

A toast will show the location where the sampling profiler has been saved, usually in /data/user/0/com.appName/cache/*.cpuprofile

You can then extract the profile from your emulator / device using the following command:

npx react-native@latest profile-hermes [destinationDir]

To view, drag and drop the profile from destinationDir into Speedscope.

Profiling in Release Mode

To profile hermes in a release build of your app, you can use the react-native-release-profiler npm package:

yarn add react-native-release-profiler
cd ios && pod install

1. Build your app in release mode
2. Start a profiling session:

import { startProfiling } from 'react-native-release-profiler'

startProfiling()

3. Stop the profiling session:

import { stopProfiling } from 'react-native-release-profiler'

// `true` to save the trace to the phone's downloads folder, `false` otherwise
const path = await stopProfiling(true)

4. Download and process the performance trace from your phone to your PC:

• On Android:

First find your app id. It should look something like com.mypackage and be visible in app/build.gradle in the defaultConfig section:

android {
    defaultConfig {
        applicationId "com.profilern" // <-- This one!
        // ...
    }
}

Then run:

npx react-native-release-profiler --fromDownload --appId <your appId>

• On iOS:

npx react-native-release-profiler --local <path to profile>

To view, drag and drop the profile saved in your current working directory into Spedscope. It should be transformed with sourcemaps!

[zacharyfmarion]

@jlfwong took a pass at some docs ^. Profiling in release mode is something that Margelo recently worked one while contracting for my company, so honestly these are probably the most up-to-date / complete docs that exist anywhere right now.

[jlfwong]

@zacharyfmarion Great! Added to the wiki, and updated the README.

Whenever you'd like to do an awareness push on Twitter or LinkedIn or wherever, let me know and I'll help signal boost.