You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Trace Event Format has listed down the various chrome events and how they are understood by the Chrome Profiler.
The Chrome Profiler consumes this profiling data in the JSON Array Format while the Hermes Profile is generated in the JSON Object Format. We might have made an oversight in assuming that the traceEvents generated by the Hermes Profiler are going to have phases assigned similar to Chrome Profiler, however this is not the case.
The phases in the case of the Hermes Profile need to be derived from the Samples and Stack Frames Properties in the Hermes Profile. This is where things are accumulated from lower level OS Kernels and we need to make sense of this data.
The text was updated successfully, but these errors were encountered:
I went through how the Chrome Profiles do this and came across the Catapult Project which basically implements the trace-viewer for Chrome. I believe we can find the way to make sense of our code by digging deep through this repository
On some research I found this systrace/profile_chrome/main.py file to be relevant to what we want to achieve. My reasons for believing so are simply based on this line in the code. This leads us to this systrace/profile_chrome/profiler.py file where a CaptureProfile Method has been implemented, now the relevant line in this method is probably the tracing_controller, which leads us to the systrace/systrace/tracing_controller.py file containing tracing code, however such tracing code is also available at other locations, for example: ftrace_events, android_events. From what I understand, the tracing_controller mentioned earlier, aggregates the events generated by these events. For the purposes for this project, I think we should pay particular emphasis on the Android Agent. However, this does require an extremely deep dive into the code. I think we should confirm with @jevakallio if we are on the right path, or if I am mistaken here.
The Trace Event Format has listed down the various chrome events and how they are understood by the Chrome Profiler.
The Chrome Profiler consumes this profiling data in the JSON Array Format while the Hermes Profile is generated in the JSON Object Format. We might have made an oversight in assuming that the traceEvents generated by the Hermes Profiler are going to have phases assigned similar to Chrome Profiler, however this is not the case.
The phases in the case of the Hermes Profile need to be derived from the Samples and Stack Frames Properties in the Hermes Profile. This is where things are accumulated from lower level OS Kernels and we need to make sense of this data.
The text was updated successfully, but these errors were encountered: