Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Min React Native/Hermes version supported? #35

Open
ryantrem opened this issue Oct 13, 2020 · 11 comments
Open

Min React Native/Hermes version supported? #35

ryantrem opened this issue Oct 13, 2020 · 11 comments

Comments

@ryantrem
Copy link

Question

I tried it out with my React Native app running on React Native 0.63.1 with Hermes enabled, but when I load the trace in Chrome Dev Tools, every item in the view is labeled as "anonymous". There are some details that list file names and line numbers specifically in the flame chart, and while the file names look like they could be correct, the line numbers make no sense when I look at the source. Additionally, the timing information doesn't make sense, as there are root level blocks in the flame graph that say they took ~250ms which is not possible as I'm using requestAnimationFrame to render graphics at 60fps.

Since it seems like it isn't really working, my question is whether there is a min version of React Native (or Hermes specifically) supported by hermes-profile-transformer. Should it work for the version of Hermes included in React Native 0.63.1?

@saphal1998
Copy link
Collaborator

saphal1998 commented Oct 22, 2020

Hi @ryantrem, sorry for the delay!

I have used this with React Native 0.62.2, so I think it should work with Hermes included in 0.63.1.

The items labelled anonymous are probably just anonymous functions, or it is possible that source maps are not provided during profiling. The information about the line numbers as well as the exact function names are extracted from source maps, so I think that is where the issue might be. In case the source maps are not provided, the function names as well as line numbers as displayed as they are in the build file.

I'm concerned about the timing information, could you share a screenshot of this and the profile itself? I want to verify the profile itself and see if the samples are taken correctly.

@ryantrem
Copy link
Author

Thanks @saphal1998 for getting back to me, much appreciated!

The items labelled anonymous are probably just anonymous functions

It seems more than just that. For example, when I click on one of the Anonymous blocks, I see these details:

Total Time 22.09 ms
Self Time 0
line 884
column 21
funcLine "128671"
funcColumn "36"
name "(http://localhost:8081/index.bundle?platform=android&dev=true&minify=false:128683:30)"
category "JavaScript"
url "/Users/ryantremblay/Repos/BabylonReactNative2/Apps/Playground/node_modules/@babylonjs/core/Engines/engine.js"
params "enterPointerlock"
allocatedCategory "@babylonjs"
allocatedName "anonymous"

So it seems like it thinks the function is enterPointerClick, but this is definitely wrong (this function is not being called), and additionally shows up as anonymous.

it is possible that source maps are not provided during profiling

I debugged the hermes-profile-transformer code a bit (while executing npx react-native profile-hermes .) and it seemed like it was finding and parsing the source map.

could you share a screenshot of this and the profile itself?

In the screenshot below, you can see blocks that are the root of the callstack taking 80+ms. My expectation would be the requestAnimationFrame callback is basically at the root of each call stack and takes no more than 16ms since I'm running at 60fps.
image

Here is the profile pictured above:
sampling-profiler-trace5987865135540939889-converted.json.zip

Also, I created a branch of my project where it is very easy to repro this by doing the following:

  1. Clone https://github.com/ryantrem/BabylonReactNative/tree/package-test-hermes-profiling
  2. In a terminal window, navigate to the Apps/PackageTest directory.
  3. Run npm install
  4. Run npx react-native run-android
  5. Open the debug menu and tap "Enable Sampling Profiler"
  6. Open the debug menu and tap "Disable Sampling Profiler"
  7. Run npx react-native profile-hermes .
  8. Load the profile in Chrome dev tools

@saphal1998
Copy link
Collaborator

saphal1998 commented Oct 24, 2020

Hi, I wasn't able to reproduce this because of

npm ERR! code ENOENT
npm ERR! syscall stat
npm ERR! path /Users/saphal/Desktop/BabylonReactNative/Package/Assembled/babylonjs-react-native-0.0.1.tgz
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, stat '/Users/saphal/BabylonReactNative/Package/Assembled/babylonjs-react-native-0.0.1.tgz'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/saphal/.npm/_logs/2020-10-24T17_28_36_275Z-debug.log

I think I might be missing this file, or something. Can you please let me know?

@ryantrem
Copy link
Author

ryantrem commented Oct 24, 2020

Thanks @saphal1998 for giving it a shot! If you cloned my repo (https://github.com/ryantrem/BabylonReactNative), then you just need to check out the branch I made for testing this out (git checkout package-test-hermes-profiling). In that branch I enabled Hermes, enabled bundle in debug (so we have source map info), and pointed the project at the official NPM package instead of a locally built package (that project is normally used to test local packages for validation before publishing, but to make the repro easy I just pointed it to the published package in this branch). As long as you have the correct branch checked out, you should have these changes locally ryantrem/BabylonReactNative@2a303fd, which are needed to test out the profiling.

@saphal1998
Copy link
Collaborator

@ryantrem Was curious if your app also crashes upon disabling profiling?

@ryantrem
Copy link
Author

It often does the first time I try, but then works on subsequent tries. I haven't tried to diagnose this yet.

@ryantrem
Copy link
Author

ryantrem commented Nov 4, 2020

Hi @saphal1998 - did you have any additional ideas on this issue?

@saphal1998
Copy link
Collaborator

Hi @ryantrem I'm not quite able to reproduce this, so I don't have any specific ideas for this issue atleast. I don't think there's a lot that can be done if the timing information is inaccurate, I tried to manually trace the function call stack as indicated by the profile, and it did make sense to me. (Just to be more sure about this, please do send me the .cpuprofile version of this profile. You can find it in the cache folder for the application on your device). There might be an issue on the Hermes end if the timing information itself doesn't seem accurate. As far as I know, Hermes profiles applications by sampling at intervals of time, by means of a timer thread. The timer thread might just not run in some cases where priority work is going on, which might lead to incorrect times being shown. But I'm not sure if this is the reason. The Hermes team is aware of this issue though, and are working on addressing it.

Although, some issues that I have identified about the metadata are -

  1. Inaccurate allocated category in the case of scoped packages

For example - BabylonReactNative/Apps/PackageTest/node_modules/@babylonjs/react-native/EngineView.tsx should have the category of react-native and not @babylonjs

  1. Better way to obtain the names of the functions

So the current way to obtain the names of the functions is by doing some regex matching with the name field, which in most cases is a name of the function followed by the url/position where we can access the function

For eg: functionA(http://localhost:8081/index.bundle?platform=android&dev=true&minify=false:128683:30)

It worked for the functions we write and the function in React, but I'm not sure why it didn't map over accurately to other packages. Something to look into perhaps.

@ryantrem
Copy link
Author

Thanks @saphal1998 - when you say:

I'm not quite able to reproduce this

Do you mean you get different results than what I shared earlier in this issue?

please do send me the .cpuprofile version of this profile

The profile I attached earlier is long gone, but I collected a new one and include the .cpuprofile file this time.

Archive.zip

Inaccurate allocated category in the case of scoped packages

In this case, what I think would be most useful (if possible) is to have the category be the full name of the scoped package (e.g. @babylonjs/react-native).

So the current way to obtain the names of the functions is by doing some regex matching with the name field

Will you point me to the code that does that?

@saphal1998
Copy link
Collaborator

Hi @ryantrem, really sorry for the very late response, somehow I didn't get notified about this, very sorry about that.

Do you mean you get different results than what I shared earlier in this issue?

No, my app seems to consistently crash on End Profiling, which is an issue on the Hermes end. Although, I will try it out as well.

The profile I attached earlier is long gone, but I collected a new one and include the .cpuprofile file this time.

Great, I can try this out.

In this case, what I think would be most useful (if possible) is to have the category be the full name of the scoped package (e.g. @babylonjs/react-native).

I agree, the code for this is here. I think we can just change dirs[2] (which points to the package name in case of non-scoped packages).

Will you point me to the code that does that?

Sure, I think this is where it is done now. For some reason, the profiles seemed to have the format of <functionName>(<bundleFileURL>), and because we are in Dev mode, the function names were accurate.

@Leena-Sharma-rsys
Copy link

Hi,
Also getting, most of the function name as Anonymous.

Sometimes on proifiling i get the function name as example as attached to the screenshot "MovieCast" , but next time if i do profiling it does not show , MovieCast ... instead it gives anonymous .
new

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants