This service provides a way to measure the time spent by various Events in a certain window. This information can be used to pinpoint performance problems in a web page or web application.
The profiler is started and stopped manually by the client, and Events are recorded for the specified window in that interval. Each such start/stop pair will produce a Session, which is explained in the section that follows.
Events that take place during profiling can currently not be sent in real-time, and are available only after the fact when profiling is stopped. This may be supported in a later version of the profiler, though.
While not required, it is highly recommended to disable other resource intensive services while profiling, especially:
Each profiling session produces a Session. A Session contains one Timeline for each frame that existed (at some point in time) during profiling.
A frame is a container for documents. A frame can contain multiple documents over time, but does not contain more than one document at once.
The documents that are loaded in frames during profiling, are also covered in the report. If multiple documents are loaded in the same frame during profiling, they will share the same Timeline.
Once a Session is created, it will continue to exist until explicitly removed with ReleaseSession, or until the service is disabled.
A timeline is a collection of Events, ordered according to the start of the Interval of each Event. The Events in the Timeline are organized in a tree, with the Timeline itself as the root Event. Each Event can have any number of children.
A child Event represents an Event which is directly triggered by another Event. The parent Event must be on the call stack when this happens for the parent-child relationship to be established. There will be no parent-child relationship between Events triggered asynchrounsly by another Event, such as a script triggering a CSS reload at a 'later time'. (This relationship, however, will be obvious to the user if the Events are presented on a Timeline).
An Event measures how long a certain operation took in Core. Examples of Events are:
- Selector matching for a certain selector.
- Imagine decoding for a certain image.
- ECMAScript execution for a certain thread.
All time fields in this service are specified in milliseconds, and time is counted since profiling began (i.e. profiling began at '0' millliseconds).
Get Events from a Timeline.
This command can extract Events from the Timeline, or a part of the Timeline. It can also process the selected Events using certain built-in operations (e.g. REDUCE_ALL) which are
Release a Session. The Session ID, and Timelines contained within the Session are no longer valid after the Session has been released.
Only stopped Session can be released.
Start profiling a window. Currently, only one profiling session is allowed at the same time. If a profiling session is already in progress, BAD_REQUEST is returned.
Stop the profiler. BAD_REQUEST is returned if we are not profiling.
When the profiler is stopped, post processing of the Timelines takes place (e.g. aggregation of timing information in the Event tree). For large trees, this process may be split up into multiple time slices, and may therefore be completed asynchronously. Profiling itself is stopped immediately when this command is received, however, the response will not be sent until post processing is done.
A user-interface should make this information clear to the user, by, for instance, indicating that the information is "loading" until the response arrives.