Define serializers for frame timings as part of HostTargetTracingProfile #54681
+1,184
−232
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: # Changelog: [Internal] This introduces a proper lifecycle for a module on Anroid that will emit frames information as part of the trace recording. Previously we would initialize it on a packager connection, which could be problematic, since there is no guarantee that InspectorTarget exists at this time. With the current approach, the lifetime of this object is: - Bound to lifetime of InspectorTarget, it will never outlive it - The actual frames listener lifetime will be bound to tracing state. We no longer will be going through `jni` to check if `PerformanceTracer` is enabled. I've renamed it to `FrameTimingsObserver`and moved to inspector package, since this should be considered as part of the inspector stack. Similarly to `LoadNetworkResource` listeners. I am keeping the `jni` layer with PerformanceTracer for now, but this is about to be removed in the diffs above. The frames information should be propagated through Host, this would allow us to record Frames even if there is no React Native instance, for example, during reloads. Differential Revision: D87345177
Summary: # Changelog: [Internal] Currently, `HostTraceRecordingState` is used everywhere and it is the final data struct that contains the tracing profile. At the same time, the original idea for it was to be a global state for Tracing Agents, where they could: 1. Read the tracing configuration, like tracing mode, enabled categories, etc. 2. Stash corresponding target profiles on reloads. For example, if `RuntimeTarget` was reloaded during tracing, `RuntimeTracingAgent` would stop JavaScript sampling profiler, and then stash this profile on a state. This change should clarify the data structures and when they are used. Differential Revision: D87830455
Summary: # Changelog: [Internal] Adding a data structure that could be configured to preserve entries that are inside of a specified time window. At the same time, this data structure could be used as a simple buffer, if no arguments were specified during constructing. This follows the approach that was added to `PerformanceTracer`, but it doesn't use pointers to avoid dealing with updates during copies or moves. Differential Revision: D87776299
Summary: # Changelog: [Internal] `HostTargetTraceRecording` will receive the tracing window size as a parameter and will propagate it to `TraceRecordingState`. This will make sure that all Tracing Agents actually aware of the window size. For example, once we add Frames to Host layer, it should use the same window size, as `PerformanceTracer`, which is initialized in `InstanceTracingAgent`. Differential Revision: D87782664
Summary: # Changelog: [Internal] This diff introduces a definition for `FrameTimingSequence`, which will represent the different phases of a frame that will be reported as part of the trace. These sequences will be stored on a `HostTargetTraceRecording`. It is `Host`'s responsibility to propagate these entities to `HostTarget`, there will be a corresponding method for this. Differential Revision: D87373811
Summary: # Changelog: [Internal] Introduces an endpoint on `HostTarget` for capturing frame timings. This exposes a public API to Host, which could be called during active tracing session. `Host` could be notified through tracing delegate in `HostTargetDelegate` about tracing state, this has been implemented below as part of this diff stack. Differential Revision: D87373807
Summary: # Changelog: [Internal] Extracing the spec for frames events to a new class `TraceEventGenerator`. This is a preparation for moving frames events to Host. Differential Revision: D87373809
Summary: # Changelog: [Internal] Now when Frame Timings are part of the whole `HostTargetTracingProfile`, we need to define how these will be serialized into chunks of `Tracing.dataCollected` messages. Differential Revision: D87373810
meta-cla
bot
added
the
CLA Signed
|
This pull request has been merged in 587d360. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Changelog: [Internal]
Now when Frame Timings are part of the whole
HostTargetTracingProfile, we need to define how these will be serialized into chunks ofTracing.dataCollectedmessages.Differential Revision: D87373810