Profiling with the built-in profiler

  • Revision slug: Performance/Profiling_with_the_Built-in_Profiler
  • Revision title: Profiling with the built-in profiler
  • Revision id: 469
  • Created:
  • Creator: Sheppy
  • Is current revision? No
  • Comment 1 words removed

Revision Content

{{ gecko_minversion_header("10.0") }}

Firefox now has a built-in profiler (codename SPS). Having a profiler in the code base lets us, amongs other things, better measure responsiveness, charge performance costs more accurately, and run in environments and platforms in which external profilers aren't available, such as in the user's environment or on a locked Android device.

Note: While the profiler platform itself is completed, there are still optional features missing that will improve the usefulness of the tool. See {{ bug("683229") }} to track the progress of the development of these features.

Stackwalking vs. pseudostack

The profiler is designed to operate in two different modes: Pseudostack (the default) or stack walking.

Pseudostack

Pseudostack (the default) requires the code base to be instrumented with SAMPLE_LABEL("NAMESPACE", "NAME");'. This adds a RAII helper on the stack that will be used by the profiler when sampling. This mode works on all platforms and environments. For this to be effective, you do need to liberally use SAMPLE_LABEL throughout the code, and unfortunately it won't be able to dig into system library and drivers.

Because of the small overhead of the instrumentation, the sample label shouldn't be placed inside hot loops. A profile reporting that a large portion is spent in "Unknown" code indicates that the area being executed doesn't have sample label. As we focus on using this tool and add additional sample labels this will improve.

Stack walking

Stack walking is an optional, platform specific, feature that isn't complete yet. The goal is to provide stack walking on any platforms that support it. Having this feature will give us a detailed stack and help us analyze problems where we're spending time in drivers and system libraries. We're working on building the proper stack walking and symbolication required to make this step work, and are looking for help with this feature.

Availability

We're still waiting on all the patches to hit mozilla-central. Until this happens here is the status of each platform:

  • Windows: Waiting on patch to land, running into some #include ordering problem.
  • Mac: Landed on mozilla-inbound, waiting on the merge.
  • Linux: Waiting for a try failure to be resolved.
  • Fennec: Landed, needs the extension ported.

Running the profiler

  1. Make sure you're using the latest version of the extension, which you can get here. It's not packaged yet, but will be once it's stabilized.
  2. Set MOZ_INSTRUMENT_EVENT_LOOP=1
  3. Start Firefox.
  4. Control the profiler from the bottom right.

Planned features

Here's a list of feature ideas that we haven't committed to yet; feel free to add your ideas:

  • A "Doctor" extension that would detect if the user's browser periodically hangs for more than 500 ms and provide a UI notification with some profile data. The profile data can either be reported to Mozilla to correlate problems, have built in heuristics for resolving the problem (disabling the offending add-on, plug-in tab, db caches etc...), or be used by support for diagnostics.
  • Automatically turn on the profiler a few seconds prior to triggering the hang detectors and attach a profile to the minidump.
  • Improvements to the web front-end Cleopatra.
  • A tracing mode that uses the pseudostack for traces rather then profile data.
  • Hooking into performance test suites.

Revision Source

<p>{{ gecko_minversion_header("10.0") }}</p>
<p>Firefox now has a built-in profiler (codename SPS). Having a profiler in the code base lets us, amongs other things, better measure responsiveness, charge performance costs more accurately, and run in environments and platforms in which external profilers aren't available, such as in the user's environment or on a locked Android device.</p>
<div class="note"><strong>Note:</strong> While the profiler platform itself is completed, there are still optional features missing that will improve the usefulness of the tool. See {{ bug("683229") }} to track the progress of the development of these features.</div>
<h2>Stackwalking vs. pseudostack</h2>
<p>The profiler is designed to operate in two different modes: Pseudostack (the default) or stack walking.</p>
<h3>Pseudostack</h3>
<p>Pseudostack (the default) requires the code base to be instrumented with <code>SAMPLE_LABEL("NAMESPACE", "NAME");'</code>. This adds a RAII helper on the stack that will be used by the profiler when sampling. This mode works on all platforms and environments. For this to be effective, you do need to liberally use <code>SAMPLE_LABEL</code> throughout the code, and unfortunately it won't be able to dig into system library and drivers.</p>
<p>Because of the small overhead of the instrumentation, the sample label shouldn't be placed inside hot loops. A profile reporting that a large portion is spent in "Unknown" code indicates that the area being executed doesn't have sample label. As we focus on using this tool and add additional sample labels this will improve.</p>
<h3>Stack walking</h3>
<p>Stack walking is an optional, platform specific, feature that isn't complete yet. The goal is to provide stack walking on any platforms that support it. Having this feature will give us a detailed stack and help us analyze problems where we're spending time in drivers and system libraries. We're working on building the proper stack walking and symbolication required to make this step work, and are looking for help with this feature.</p>
<h2>Availability</h2>
<p>We're still waiting on all the patches to hit <a href="/en/mozilla-central" title="mozilla-central">mozilla-central</a>. Until this happens here is the status of each platform:</p>
<ul> <li>Windows: Waiting on patch to land, running into some #include ordering problem.</li> <li>Mac: Landed on mozilla-inbound, waiting on the merge.</li> <li>Linux: Waiting for a try failure to be resolved.</li> <li>Fennec: Landed, needs the extension ported.</li>
</ul>
<h2>Running the profiler</h2>
<ol> <li>Make sure you're using the <a class="link-https" href="https://builder.addons.mozilla.org/addon/1023834/latest/" title="https://builder.addons.mozilla.org/addon/1023834/latest/">latest version of the extension</a>, which you can get here. It's not packaged yet, but will be once it's stabilized.</li> <li>Set <code>MOZ_INSTRUMENT_EVENT_LOOP=1</code></li> <li>Start Firefox.</li> <li>Control the profiler from the bottom right.</li>
</ol>
<h3>Planned features</h3>
<p>Here's a list of feature ideas that we haven't committed to yet; feel free to add your ideas:</p>
<ul> <li>A "Doctor" extension that would detect if the user's browser periodically hangs for more than 500 ms and provide a UI notification with some profile data. The profile data can either be reported to Mozilla to correlate problems, have built in heuristics for resolving the problem (disabling the offending add-on, plug-in tab, db caches etc...), or be used by support for diagnostics.</li> <li>Automatically turn on the profiler a few seconds prior to triggering the hang detectors and attach a profile to the minidump.</li> <li>Improvements to the web front-end Cleopatra.</li> <li>A tracing mode that uses the pseudostack for traces rather then profile data.</li> <li>Hooking into performance test suites.</li>
</ul>
<p><a class="external" href="http://dl.dropbox.com/u/10523664/Screenshots/2c.png"><img alt="" class="default" src="http://dl.dropbox.com/u/10523664/Screenshots/2c.png" style="width: 810px; height: 630px;"></a></p>
Revert to this revision