DevTools/OperationInstrument: Difference between revisions

DevTools/OperationInstrument (view source)

Revision as of 17:52, 9 April 2015

616 bytes added , 9 April 2015

more edits

Fitzgen

Confirmed users

125

edits

@@ Line 9: / Line 9: @@
 === Platform ===
-The '''<code>TimelineMarker</code>''' class is defined in <code>docshell/base/TimelineMarker.h</code>. A timestamp, and the JS stack (if any) is recorded when the marker is instantiated. The stack is recorded when a start marker is instantiated. It's possible to pass metadata which will be used in the performance tool. For now, only the main thread is instrumented. Markers are stored in the docshell being profiled. To store a marker: nsDocShell->AddProfileTimelineMarker(). See nsDocShell.h. Markers are popped out from the docshell at regular interval via nsIDocShell.popProfileTimelineMarkers() by devtools code (timeline actor). See nsIDocShell.idl and toolkit/devtools/server/actors/timeline.js.
+The easiest way to trace Gecko events/tasks with start and end timeline markers is to use the '''<code>mozilla::AutoTimelineMarker</code>''' RAII class. It automatically adds the start marker on construction, and adds the end marker on destruction. Don't worry too much about potential performance impact! It only actually adds the markers when the given docshell is being recorded.
-See '''Part 1''' in the example bug above.
   --- a/dom/base/nsContentUtils.cpp
@@ Line 24: / Line 22: @@
                                      bool aPreventScriptExecution)
    {
-  +  AutoTimelineMarker m(aTargetNode->OwnerDoc()->GetDocShell(), "Parse HTML");
+  +  AutoTimelineMarker marker(aTargetNode->OwnerDoc()->GetDocShell(), "Parse HTML");
   +
      if (nsContentUtils::sFragmentParsingActive) {
@@ Line 34: / Line 32: @@
      if (!sHTMLFragmentParser) {
        NS_ADDREF(sHTMLFragmentParser = new nsHtml5StringParser());
+Under the hood, AutoTimelineMarker is using the '''<code>TimelineMarker</code>''' class is defined in '''<code>docshell/base/TimelineMarker.h</code>'''. A timestamp and the current JS stack (if any) is recorded when the marker is instantiated. It's also possible to attach arbitrary metadata to a marker by subclassing <code>TimelineMarker</code>, which can then be displayed in the performance tool frontend. Markers are stored in the docshell being profiled. To store a marker, call '''<code>nsDocShell->AddProfileTimelineMarker()</code>'''. See '''<code>docshell/base/nsDocShell.h</code>'''. Markers are popped out from the docshell at regular interval via <code>nsIDocShell.popProfileTimelineMarkers()</code> by devtools code (timeline actor). See <code>docshell/base/nsIDocShell.idl</code> and <code>toolkit/devtools/server/actors/timeline.js</code>.
+For now, only the main thread is instrumented.
 === Frontend ===
-The performance tool expects some pre-defined type of markers. Defined in '''<code>browser/devtools/timeline/widgets/global.js</code>'''. To add new support for new markers in the UI, updating this file is enough. To display marker's metadata - if any (displayed when marker is selected in the waterfall) add a rendering function in '''<code>browser/devtools/timeline/widgets/marker-details.js</code>'''.
+To get your new markers displayed in the performance tool's UI, edit the config data in '''<code>browser/devtools/shared/timeline/global.js</code>'''. To add new support for new markers in the UI, updating this file is enough.
 https://developer.mozilla.org/en-US/docs/Tools/DevToolsColors#Highlight_Colors
@@ Line 85: / Line 87: @@
    # AS SHORT AS POSSIBLE so it doesn't obstruct important parts of the graph.
    graphs.memory=MB
+For displaying new markers, that is enough. To display a marker's custom metadata - if any (displayed when the marker is selected in the waterfall) add a rendering function in '''<code>browser/devtools/timeline/widgets/marker-details.js</code>'''.
 === Recording markers in a different thread ===