General text edits to content-tracing
This commit is contained in:
parent
0a4144e67a
commit
3001ef7980
1 changed files with 16 additions and 16 deletions
|
@ -1,6 +1,6 @@
|
|||
# content-trace
|
||||
# content-tracing
|
||||
|
||||
The `content-trace` module is used to collect tracing data generated by the
|
||||
The `content-tracing` module is used to collect tracing data generated by the
|
||||
underlying Chromium content module. This module does not include a web interface
|
||||
so you need to open `chrome://tracing/` in a Chrome browser and load the
|
||||
generated file to view the result.
|
||||
|
@ -20,7 +20,7 @@ tracing.startRecording('*', tracing.DEFAULT_OPTIONS, function() {
|
|||
|
||||
## Methods
|
||||
|
||||
- The `content-trace` module has the following methods:
|
||||
The `content-tracing` module has the following methods:
|
||||
|
||||
### `tracing.getCategories(callback)`
|
||||
|
||||
|
@ -29,8 +29,8 @@ tracing.startRecording('*', tracing.DEFAULT_OPTIONS, function() {
|
|||
Get a set of category groups. The category groups can change as new code paths
|
||||
are reached.
|
||||
|
||||
Once all child processes have acked to the `getCategories` request, `callback`
|
||||
is invoked with an array of category groups.
|
||||
Once all child processes have acknowledged the `getCategories` request the
|
||||
`callback` is invoked with an array of category groups.
|
||||
|
||||
### `tracing.startRecording(categoryFilter, traceOptions, callback)`
|
||||
|
||||
|
@ -42,7 +42,7 @@ Start recording on all processes.
|
|||
|
||||
Recording begins immediately locally and asynchronously on child processes
|
||||
as soon as they receive the EnableRecording request. Once all child processes
|
||||
have acked to the `startRecording` request the `callback` will be called.
|
||||
have acknowledged the `startRecording` request the `callback` will be called.
|
||||
|
||||
`categoryFilter` is a filter to control what category groups should be
|
||||
traced. A filter can have an optional `-` prefix to exclude category groups
|
||||
|
@ -66,8 +66,8 @@ list. Possible options are:
|
|||
|
||||
The first 3 options are trace recoding modes and hence mutually exclusive.
|
||||
If more than one trace recording modes appear in the `traceOptions` string,
|
||||
the last one takes precedence. If none of the trace recording mode is specified,
|
||||
recording mode is `record-until-full`.
|
||||
the last one takes precedence. If none of the trace recording modes is
|
||||
specified, recording mode is `record-until-full`.
|
||||
|
||||
The trace option will first be reset to the default option (record_mode set to
|
||||
`record-until-full`, enable_sampling and enable_systrace set to `false`)
|
||||
|
@ -86,8 +86,8 @@ operation to send the trace data over IPC, and we would like to avoid runtime
|
|||
overhead of tracing. So, to end tracing, we must asynchronously ask all
|
||||
child processes to flush any pending trace data.
|
||||
|
||||
Once all child processes have acked to the `stopRecording` request, `callback`
|
||||
will be called with a file that contains the traced data.
|
||||
Once all child processes have acknowledged the `stopRecording` request,
|
||||
`callback` will be called with a file that contains the traced data.
|
||||
|
||||
Trace data will be written into `resultFilePath` if it is not empty or into a
|
||||
temporary file. The actual file path will be passed to `callback` if it's not
|
||||
|
@ -104,7 +104,7 @@ Start monitoring on all processes.
|
|||
Monitoring begins immediately locally and asynchronously on child processes as
|
||||
soon as they receive the `startMonitoring` request.
|
||||
|
||||
Once all child processes have acked to the `startMonitoring` request the
|
||||
Once all child processes have acknowledged the `startMonitoring` request the
|
||||
`callback` will be called.
|
||||
|
||||
### `tracing.stopMonitoring(callback)`
|
||||
|
@ -113,7 +113,7 @@ Once all child processes have acked to the `startMonitoring` request the
|
|||
|
||||
Stop monitoring on all processes.
|
||||
|
||||
Once all child processes have acked to the `stopMonitoring` request the
|
||||
Once all child processes have acknowledged the `stopMonitoring` request the
|
||||
`callback` is called.
|
||||
|
||||
### `tracing.captureMonitoringSnapshot(resultFilePath, callback)`
|
||||
|
@ -123,14 +123,14 @@ Once all child processes have acked to the `stopMonitoring` request the
|
|||
|
||||
Get the current monitoring traced data.
|
||||
|
||||
Child processes typically are caching trace data and only rarely flush and send
|
||||
trace data back to the main process. That is because it may be an expensive
|
||||
Child processes are typically caching trace data and only rarely flush and send
|
||||
trace data back to the main process. This is because it may be an expensive
|
||||
operation to send the trace data over IPC and we would like to avoid unneeded
|
||||
runtime overhead from tracing. So, to end tracing, we must asynchronously ask
|
||||
all child processes to flush any pending trace data.
|
||||
|
||||
Once all child processes have acked to the `captureMonitoringSnapshot` request
|
||||
the `callback` will be called with a file that contains the traced data.
|
||||
Once all child processes have acknowledged the `captureMonitoringSnapshot`
|
||||
request the `callback` will be called with a file that contains the traced data.
|
||||
|
||||
|
||||
### `tracing.getTraceBufferUsage(callback)`
|
||||
|
|
Loading…
Add table
Reference in a new issue