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 currently proposed profile format works for recording CPU profiles, where a single sample can be correlated to the amount of CPU time. It might be good, though, to add fields which can be used to track specific metrics associated with each sample (like number of samples, or seconds of CPU time).
There are two benefits to modifying the profile to support tracking more specific metrics. First, it would not be necessary for users to check profiler.options.sampleInterval to determine the CPU time associated with each sample, since this information would be a part of the profile. Next, tracking specific metrics could make it easier to extend this profile format so it could be used to record other profile types (for example, for heap profiles one would want to track objects allocated and bytes allocated).
To support this, I’d propose modifications like the following could be made to the proposed profile format:
Add a "metricTypes" field to the profile, to track the type of each recorded metric. This field will be an array of objects which specify the unit and types for each metric.
For example, for a CPU profile, the "metricTypes" would be:
Then, in the sample in the "samples" field, there would be an array, "metrics", recording the value for each metric for that sample. The length of the array for "metricTypes" would be the same as the length of the "metrics" array for each sample.
The currently proposed profile format works for recording CPU profiles, where a single sample can be correlated to the amount of CPU time. It might be good, though, to add fields which can be used to track specific metrics associated with each sample (like number of samples, or seconds of CPU time).
There are two benefits to modifying the profile to support tracking more specific metrics. First, it would not be necessary for users to check
profiler.options.sampleInterval
to determine the CPU time associated with each sample, since this information would be a part of the profile. Next, tracking specific metrics could make it easier to extend this profile format so it could be used to record other profile types (for example, for heap profiles one would want to track objects allocated and bytes allocated).To support this, I’d propose modifications like the following could be made to the proposed profile format:
Add a
"metricTypes"
field to the profile, to track the type of each recorded metric. This field will be an array of objects which specify the unit and types for each metric.For example, for a CPU profile, the
"metricTypes"
would be:If, in the future, this format were used to record heap profiles, the
"metricTypes"
field would be:Then, in the sample in the
"samples"
field, there would be an array,"metrics"
, recording the value for each metric for that sample. The length of the array for"metricTypes"
would be the same as the length of the"metrics"
array for each sample.For example, if
"metricTypes"
were:The samples might look like for a profile which sampled every 1ms:
Full example profile:
The text was updated successfully, but these errors were encountered: