diff options
Diffstat (limited to 'files/my/mozilla/performance')
| -rw-r--r-- | files/my/mozilla/performance/adding_a_new_telemetry_probe/index.html | 184 | ||||
| -rw-r--r-- | files/my/mozilla/performance/index.html | 143 |
2 files changed, 327 insertions, 0 deletions
diff --git a/files/my/mozilla/performance/adding_a_new_telemetry_probe/index.html b/files/my/mozilla/performance/adding_a_new_telemetry_probe/index.html new file mode 100644 index 0000000000..b706bfd185 --- /dev/null +++ b/files/my/mozilla/performance/adding_a_new_telemetry_probe/index.html @@ -0,0 +1,184 @@ +--- +title: Adding a new Telemetry probe +slug: Mozilla/Performance/Adding_a_new_Telemetry_probe +translation_of: Mozilla/Performance/Adding_a_new_Telemetry_probe +--- +<p>If a user has opted into submitting performance data to Mozilla, the Telemetry system will collect various measures of Firefox performance, hardware, usage and customizations and submit it to Mozilla. The Telemetry data collected by a single client can be examined from the integrated <em>about:telemetry</em> browser page, while the aggregated reports across entire user populations are publicly available at <a href="https://telemetry.mozilla.org">https://telemetry.mozilla.org</a>.</p> + +<div class="warning"> +<p><strong>Note: </strong>Every new data collection in Firefox now needs a <a href="https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval">data collection review</a> from a data collection peer. Just set the feedback? flag for :bsmedberg or one of the other data peers. We try to reply within a business day.</p> +</div> + +<p>The following sections explain how to add a new measurement to Telemetry.</p> + +<h2 id="Telemetry_Histograms">Telemetry Histograms</h2> + +<p>Telemetry histograms are the preferred way to track numeric measurements such as timings. Telemetry also tracks more complex data types such as slow SQL statement strings, browser hang stacks and system configurations. Most of these non-histogram measurements are maintained by the <a href="https://wiki.mozilla.org/Telemetry#People">Telemetry team</a>, so they are not covered in this document. If you need to add a non-histogram measurement, contact that team first.</p> + +<p>The histogram below is taken from Firefox's <em>about:telemetry</em> page. It shows a histogram used for tracking plugin shutdown times and the data collected over a single Firefox session. The timing data is grouped into buckets where the height of the blue bars represents the number of items in each bucket. The tallest bar, for example, indicates that there were 63 plugin shutdowns lasting between 129ms and 204ms.</p> + +<p><img alt="Sample Telemetry histogram "PLUGIN_SHUTDOWN_MS" taken from Firefox's about:telemetry page" src="/files/4437/sampleHistogram.png" style="height: 376px; width: 328px;"></p> + +<h2 id="Choosing_a_Histogram_Type">Choosing a Histogram Type</h2> + +<p>The first step to adding a new histogram is to choose the histogram type that best represents the data being measured. The sample histogram used above is an "exponential" histogram.</p> + +<div class="note"> +<p>Ony <strong>flag</strong> and <strong>count</strong> histograms have default values. All other histograms start out empty and are not submitted if no value is recorded for them.</p> +</div> + +<p>The following types are available:</p> + +<ul> + <li><strong>flag:</strong> This histogram type allows you to record a single value (<code>0</code> or <code>1</code>, default <code>0</code>). This type is useful if you need to track whether a feature was ever used during a Firefox session. You only need to add a single line of code which sets the flag when the feature is used because the histogram is initialized with a default value of <code>0</code>/<code>false</code> (flag not set). Thus, recording a value of <code>0</code> is not allowed and asserts.</li> + <li><strong>boolean</strong>: These histograms only record boolean values. Multiple boolean entries can be recorded in the same histogram during a single browsing session, e.g. if a histogram is measuring user choices in a dialog box with options "Yes" or "No", a new boolean value is added every time the dialog is displayed.</li> + <li><strong>count</strong>: This histogram type is used when you want to record a count of something. It only stores a single value and defaults to <code>0</code>. + <div class="warning"> + <p>Count histograms and keyed histograms are fully supported only in our V4 pipeline tools, such as the <a href="https://telemetry.mozilla.org/">unified telemetry (v4) dashboards</a>. These are not fully supported in Telemetry v2 pipeline tools such as the <a href="https://alerts.telemetry.mozilla.org/index.html">histogram change detector</a>.</p> + </div> + </li> + <li><strong>enumerated</strong>: This histogram type is intended for storing "enum" values. An enumerated histogram consists of a fixed number of "buckets", each of which is associated with a consecutive integer value (the bucket's "label"). Each bucket corresponds to an enum value and counts the number of times its particular enum value was recorded. You might use this type of histogram if, for example, you wanted to track the relative popularity of SSL handshake types. Whenever the browser started an SSL handshake, it would record one of a limited number of enum values which uniquely identifies the handshake type. + <div class="note"> + <p>Set "n_buckets" to a slightly larger value than needed to allow for new enum values in the future. The current Telemetry server does not support changing histogram declarations after the histogram has already been released. See <a href="#Miscellaneous">Miscellaneous section</a>.</p> + </div> + </li> + <li><strong>linear:</strong> Linear histograms are similar to enumerated histograms, except each bucket is associated with a range of values instead of a single enum value. The range of values covered by each bucket increases linearly from the previous bucket, e.g. one bucket might count the number of occurrences of values between 0 to 9, the next bucket would cover values 10-19, the next 20-29, etc. This bucket type is useful if there aren't orders of magnitude differences between the minimum and maximum values stored in the histogram, e.g. if the values you are storing are percentages 0-100%. + <div class="note"> + <p>If you need a linear histogram with buckets < 0, 1, 2 ... N >, then you should declare an enumerated histogram. This restriction was added to prevent developers from making a common off-by-one mistake when specifying the number of buckets in a linear histogram.</p> + </div> + </li> + <li><strong>categorical: </strong>Categorical histograms are similar to enumerated histograms. However, instead of specifying <code>n</code>_<code>buckets</code>, you specify an array of strings in the <code>labels</code> field. From JavaScript, the label values or their indices can be passed as strings to <code>histogram.add()</code>. From C++ you can use<code> AccumulateCategorical()</code> with passing a value from the corresponding <code>Telemetry::LABEL_*</code> enum, or, in exceptional cases the string values. + <div class="note"> + <p>If you need to add new labels, you should use a new histogram name. The current Telemetry server does not support changing histogram declarations after the histogram has already been released. See <a href="#Miscellaneous">Miscellaneous section</a>.</p> + </div> + </li> + <li> + <p><strong>exponential:</strong> Exponential histograms are similar to linear histograms but the range of values covered by each bucket increases exponentially. As an example of its use, consider the timings of an I/O operation whose duration might normally fall in the range of 0ms-50ms but extreme cases might have durations in seconds or minutes. For such measurements, you would want finer-grained bucketing in the normal range but coarser-grained bucketing for the extremely large values. An exponential histogram fits this requirement since it has "narrow" buckets near the minimum value and significantly "wider" buckets near the maximum value.</p> + </li> +</ul> + +<h3 id="Keyed_Histograms">Keyed Histograms</h3> + +<p>Keyed histograms are collections of one of the histogram types above, indexed by a string key. This is for example useful when you want to break down certain counts by a name, like how often searches happen with which search engine.</p> + +<div class="warning"> +<p>Count histograms and keyed histograms are fully supported only in our V4 pipeline tools, such as the <a href="https://telemetry.mozilla.org/">unified telemetry (v4) dashboards</a>. These are not fully supported in Telemetry v2 pipeline tools such as the <a href="https://alerts.telemetry.mozilla.org/index.html">histogram change detector</a>.</p> +</div> + +<h2 id="Declaring_a_Histogram">Declaring a Histogram</h2> + +<p>Histograms should be declared in the <a href="https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json">toolkit/components/telemetry/Histograms.json</a> file. These declarations are checked for correctness at <a href="https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/gen-histogram-data.py">compile time</a> and used to generate C++ code. It is also possible to create histograms at runtime dynamically, but this is primarily done by add-ons when they create their own histograms in Telemetry.</p> + +<p>The following is a sample histogram declaration from <em>Histograms.json</em> for a histogram named <code>MEMORY_RESIDENT</code> which tracks the amount of resident memory used by a process:</p> + +<pre class="brush: js">"MEMORY_RESIDENT": { + "alert_emails": ["team@mozilla.xyz"], + "expires_in_version": "never", + "kind": "exponential", + "low": "32 * 1024", + "high": "1024 * 1024", + "n_buckets": 50, + "bug_numbers": [12345], + "description": "Resident memory size (KB)" +},</pre> + +<p>Note that histogram declarations in <em>Histograms.json</em> are converted to C++ code so the right-hand sides of fields can be the names of C++ constants or simple expressions as in the "low" and "high" fields above.</p> + +<p>The possible fields in a histogram declaration are:</p> + +<ul> + <li><strong>alert_emails</strong>: Required for all new histograms. This field is a list of e-mail addresses that should be notified when the distribution of the histogram changes significantly from one build-id to the other. This can be useful to detect regressions. Note that all alerts will be sent automatically to mozilla.dev.telemetry-alerts.</li> + <li><strong>expires_in_version: </strong>Required. The version number in which the histogram expires; e.g. a value of <code>"30"</code> will mean that the histogram stops recording from Firefox 30 on. A version number of type <code>"N"</code> and <code>"N.0"</code> is automatically converted to <code>"N.0a1"</code> in order to expire the histogram also in the development channels. For histograms that never expire the value <code>"never"</code> can be used as in the example above. Accumulating data into an expired histogram is effectively a non-op and will not record anything.</li> + <li><strong>kind</strong>: Required. One of the histogram types described in the previous section. Different histogram types require different fields to be present in the declaration.</li> + <li><strong>keyed:</strong> Optional, boolean, defaults to <code>false</code>. Determines whether this is a <em>keyed histogram</em>.</li> + <li><strong>low</strong>: Optional, the default value is 1. This field represents the minimum value expected in the histogram. Note that all histograms automatically get a bucket with label "0" for counting values below the "low" value.</li> + <li><strong>high</strong>: Required for linear and exponential histograms. The maximum value to be stored in a linear or exponential histogram. Any recorded values greater than this maximum will be counted in the last bucket.</li> + <li><strong>n_buckets</strong>: Required for linear and exponential histograms. The number of buckets in a linear or exponential histogram.</li> + <li><strong>n_values</strong>: Required for enumerated histograms. Similar to n_buckets, it represent the number of elements in the enum.</li> + <li><strong>labels</strong>: Required for categorical histograms. This is an array of strings which are the labels for different values in this histograms. The labels are restricted to a C++-friendly subset of characters (<code>^[a-z][a-z0-9_]+[a-z0-9]$</code>).</li> + <li><strong>bug_numbers</strong>: Required for all new histograms. This is an array of integers and should at least contain the bug number that added the probe and additionally other bug numbers that affected its behavior.</li> + <li><strong>description</strong>: Required. A description of the data tracked by the histogram, e.g. <em>"Resident memory size"</em></li> + <li><strong>cpp_guard</strong>: Optional. This field inserts an #ifdef directive around the histogram's C++ declaration. This is typically used for platform-specific histograms, e.g. "cpp_guard": "ANDROID"</li> + <li><strong>releaseChannelCollection:</strong> Optional. This is one of: + <ul> + <li>"opt-in": (default value) This histogram is submitted by default on pre-release channels; on the release channel only if the user opted into additional data collection</li> + <li>"opt-out": This histogram is submitted by default on release and pre-release channels, unless the user opted out. + <div class="warning">Because they are collected by default, opt-out probes need to meet a higher "user benefit" threshold than opt-in probes.<br> + <br> + Make sure you've NEEDINFO'd a privacy peer for <strong>ALL </strong>new data collection: <a href="https://wiki.mozilla.org/Firefox/Data_Collection">https://wiki.mozilla.org/Firefox/Data_Collection</a></div> + </li> + </ul> + </li> +</ul> + +<h2 id="Adding_a_JavaScript_Probe">Adding a JavaScript Probe</h2> + +<p>A Telemetry probe is the code that measures and stores values in a histogram. Probes in privileged JavaScript code can make use of the <a href="https://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/nsITelemetry.idl">nsITelemetry</a> interface to get references to histogram objects. A new value is recorded in the histogram by calling <code>add</code> on the histogram object:</p> + +<pre class="brush: js">let histogram = Services.telemetry.getHistogramById("PLACES_AUTOCOMPLETE_1ST_RESULT_TIME_MS"); +histogram.add(measuredDuration); + +let keyed = Services.telemetry.getKeyedHistogramById("TAG_SEEN_COUNTS"); +keyed.add("blink");</pre> + +<p>For histogram measuring time, <a href="https://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/TelemetryStopwatch.jsm">TelemetryStopwatch</a> can also be used to avoid working with Dates manually:</p> + +<pre class="brush: js">TelemetryStopwatch.start("SEARCH_SERVICE_INIT_MS"); +TelemetryStopwatch.finish("SEARCH_SERVICE_INIT_MS"); + +TelemetryStopwatch.start("FX_TAB_SWITCH_TOTAL_MS"); +TelemetryStopwatch.cancel("FX_TAB_SWITCH_TOTAL_MS"); +</pre> + +<h2 id="Adding_a_C_Probe">Adding a C++ Probe</h2> + +<p>Probes in native code can also use the <a href="https://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/nsITelemetry.idl">nsITelemetry</a> interface, but the helper functions declared in <a href="https://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Telemetry.h">Telemetry.h</a> are more convenient:</p> + +<pre class="brush: cpp">#include "mozilla/Telemetry.h" + +/** + * Adds sample to a histogram defined in Histograms.json + * + * @param id - histogram id + * @param sample - value to record. + */ +void Accumulate(ID id, uint32_t sample); + +/** + * Adds time delta in milliseconds to a histogram defined in Histograms.json + * + * @param id - histogram id + * @param start - start time + * @param end - end time + */ +void AccumulateTimeDelta(ID id, TimeStamp start, TimeStamp end = TimeStamp::Now());</pre> + +<p>The histogram names declared in <em>Histograms.json</em> are translated into constants in the <code>mozilla::Telemetry</code> namespace:</p> + +<pre class="brush: cpp">mozilla::Telemetry::Accumulate(mozilla::Telemetry::STARTUP_CRASH_DETECTED, true);</pre> + +<p>The <em>Telemetry.h</em> header also declares the helper classes <code>AutoTimer</code> and <code>AutoCounter</code>. Objects of these types automatically record a histogram value when they go out of scope:</p> + +<pre class="brush: cpp">nsresult +nsPluginHost::StopPluginInstance(nsNPAPIPluginInstance* aInstance) +{ + Telemetry::AutoTimer<Telemetry::PLUGIN_SHUTDOWN_MS> timer; + ... + return NS_OK; +} +</pre> + +<h2 id="Miscellaneous_2"><a id="Miscellaneous" name="Miscellaneous"></a>Miscellaneous</h2> + +<ul> + <li>Changing histogram declarations after the histogram has been released is tricky. You will need to create a new histogram with the new parameters. + <ul> + <li>For enum histograms, it's prudent to set "n_buckets" to a slightly larger value than needed since new elements may be added to the enum in the future.</li> + </ul> + </li> + <li><code>getHistogramById</code> will throw an NS_ERROR_ILLEGAL_VALUE JavaScript exception if it is called with an invalid histogram ID</li> + <li>Flag histograms will ignore any changes after the flag is set, so once the flag is set, it cannot be unset</li> + <li>Histograms which track timings in milliseconds or microseconds should suffix their names with "_MS" and "_US" respectively. Flag-type histograms should have the suffix "_FLAG" in their name.</li> + <li>If a histogram does not specify a "low" value, it will always have a "0" bucket (for negative or zero values) and a "1" bucket (for values between 1 and the next bucket)</li> + <li>The histograms on the <em>about:telemetry</em> page only show the non-empty buckets in a histogram except for the bucket to the left of the first non-empty bucket and the bucket to the right of the last non-empty bucket</li> +</ul> diff --git a/files/my/mozilla/performance/index.html b/files/my/mozilla/performance/index.html new file mode 100644 index 0000000000..82c169862a --- /dev/null +++ b/files/my/mozilla/performance/index.html @@ -0,0 +1,143 @@ +--- +title: Performance +slug: Mozilla/Performance +tags: + - Add-ons + - Debugging + - Development + - Mozilla + - NeedsTranslation + - Performance + - TopicStub +translation_of: Mozilla/Performance +--- +<p>The articles linked to from here will help you improve performance, whether you're developing core Mozilla code or an add-on.</p> + +<table class="topicpage-table"> + <tbody> + <tr> + <td> + <h3 id="Documentation">Documentation</h3> + + <dl> + <dt><a href="/en/Performance/Reporting_a_Performance_Problem" title="en/Performance/Reporting_a_Performance_Problem">Reporting a Performance Problem</a></dt> + <dd>A user friendly guide to reporting a performance problem. A development environment is not required.</dd> + <dt><a href="Benchmarking" title="Performance/Benchmarking advice">Benchmarking</a></dt> + <dd>Tips on generating valid performance metrics.</dd> + <dt><a href="/en/Extensions/Performance_best_practices_in_extensions" title="en/Extensions/Performance best practices in extensions">Performance best practices in extensions</a></dt> + <dd>A performance "best practices" guide for extension developers.</dd> + <dt><a href="/en/Performance/Measuring_add-on_startup_performance" title="en/Measuring Add-on Startup Performance">Measuring Add-on Startup Performance</a></dt> + <dd>A guide for add-on developers on how to set up a performance testing environment.</dd> + <dt><a href="/en/XUL_School/Appendix_A:_Add-on_Performance" title="en/XUL School/Appendix A: Add-on Performance">XUL School: Add-on Performance</a></dt> + <dd>Tips for add-on developers to help them avoid impairing application performance.</dd> + <dt><a href="/en/Performance/GPU_performance" title="en/GPU performance">GPU performance</a></dt> + <dd>Tips for profiling and improving performance when using a GPU.</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/ScrollLinkedEffects">Scroll-Linked Effects</a></dt> + <dd>Information on scroll-linked effects, their effect on performance, related tools, and possible mitigation techniques.</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/Automated_Performance_Testing_and_Sheriffing">Automated Performance Testing and Sheriffing</a></dt> + <dd>Information on automated performance testing and sheriffing at Mozilla.</dd> + </dl> + + <p><span class="alllinks"><a class="internal" href="/Special:Tags?tag=Performance" title="Special:Tags?tag=Performance">View all pages tagged with "Performance"...</a></span></p> + + <h3 id="Memory_profiling_and_leak_detection_tools">Memory profiling and leak detection tools</h3> + + <dl> + <dt><a href="https://developer.mozilla.org/en-US/docs/Tools/Memory" title="en/Performance/Profiling with the Built-in Profiler">The Developer Tools "Memory" panel</a></dt> + <dd>The memory panel in the devtools supports taking heap snapshots, diffing them, computing dominator trees to surface "heavy retainers", and recording allocation stacks.</dd> + </dl> + + <dl> + <dt><a href="/en-US/docs/Mozilla/Performance/about:memory">about:memory</a></dt> + <dd>about:memory is the easiest-to-use tool for measuring memory usage in Mozilla code, and is the best place to start. It also lets you do other memory-related operations like trigger GC and CC, dump GC & CC logs, and dump DMD reports. about:memory is built on top of Firefox's <a href="/en-US/docs/Mozilla/Performance/Memory_reporting">memory reporting</a> infrastructure.</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/DMD">DMD</a></dt> + <dd>DMD is a tool that identifies shortcomings in about:memory's measurements, and can also do multiple kinds of general heap profiling.</dd> + <dt><a href="https://areweslimyet.com/">areweslimyet.com</a></dt> + <dd>areweslimyet.com (a.k.a. AWSY) is a memory usage and regression tracker.</dd> + <dt><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Performance/BloatView">BloatView</a></dt> + <dd>BloatView prints per-class statistics on allocations and refcounts, and provides gross numbers on the amount of memory being leaked broken down by class. It is used as part of Mozilla's continuous integration testing.</dd> + <dt><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Refcount_tracing_and_balancing">Refcount tracing and balancing</a></dt> + <dd>Refcount tracing and balancing are ways to track down leaks caused by incorrect uses of reference counting. They are slow and not particular easy to use, and thus most suitable for use by expert developers.</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/GC_and_CC_logs">GC and CC logs</a></dt> + <dd>GC and CC logs can be generated and analyzed to in various ways. In particular, they can help you understand why a particular object is being kept alive.</dd> + <dt><a href="/en-US/docs/Mozilla/Testing/Valgrind">Valgrind</a></dt> + <dd><a class="external text" href="http://valgrind.org/" rel="nofollow">Valgrind</a> is a tool that detects various memory-related problems at runtime, including leaks. Valgrind is used as <a class="external text" href="/en-US/docs/Valgrind_test_job" rel="nofollow">part</a> of Mozilla's continuous integration testing, though the coverage is limited because Valgrind is slow.</dd> + <dt><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Testing/Firefox_and_Address_Sanitizer#LeakSanitizer">LeakSanitizer</a></dt> + <dd><span class="external text">LeakSanitizer</span> (a.k.a. LSAN) is similar to Valgrind, but it runs faster because it uses static source code instrumentation. LSAN is part of Mozilla's continuous integration testing, with most tests running through it as part of the AddressSanitizer (a.k.a. ASAN) test jobs.</dd> + <dt><a href="http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html">Apple tools</a></dt> + <dd>Apple provides <span class="external text">some tools</span> for Mac OS X that report similar problems to those reported by LSAN and Valgrind. The "leaks" tool is not recommended for use with SpiderMonkey or Firefox, because it gets confused by tagged pointers and thinks objects have leaked when they have not (see <a class="external text" href="https://bugzilla.mozilla.org/show_bug.cgi?id=390944" rel="nofollow">bug 390944</a>).</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/Leak_Gauge">Leak Gauge</a></dt> + <dd>Leak Gauge is a tool that can be used to detect certain kinds of leaks in Gecko, including those involving documents, window objects, and docshells.</dd> + <dt><a href="http://dxr.mozilla.org/mozilla-central/source/memory/replace/logalloc/README">LogAlloc</a></dt> + <dd>LogAlloc is a tool that dumps a log of memory allocations in Gecko. That log can then be replayed against Firefox's default memory allocator independently or through another replace-malloc library, allowing the testing of other allocators under the exact same workload.</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/Memory_Profiler">Memory Profiler</a></dt> + <dd>The memory profiler samples allocation events and provides different views to analyze the allocation characteristic.</dd> + </dl> + + <p>See also the documentation on <a href="/en-US/docs/Mozilla/Performance/Leak-hunting_strategies_and_tips">Leak-hunting strategies and tips.</a></p> + </td> + <td> + <h3 id="Profiling_and_performance_tools">Profiling and performance tools</h3> + + <dl> + <dt><a href="https://developer.mozilla.org/en-US/docs/Tools/Performance" title="en/Performance/Profiling with the Built-in Profiler">Profiling with the Developer Tools Profiler</a></dt> + <dd>The profiler built into the developer tools has a high-level waterfall, detailed call tree, allocations and GC profiling, and flame graphs. It is available on all platforms and release channels, and also supports remote profiling b2g and Fennec.</dd> + </dl> + + <dl> + <dt><a href="/en/Performance/Profiling_with_the_Built-in_Profiler" title="en/Performance/Profiling with the Built-in Profiler">Profiling with the Gecko Profiler Addon</a> {{ gecko_minversion_inline("16.0") }}</dt> + <dd>The Gecko Profiler Addon is a good tool to start with.</dd> + <dt><a href="/en/Performance/Profiling_with_Instruments" title="en/Performance/Profiling with Instruments">Profiling with Instruments</a></dt> + <dd>How to use Apple's Instruments tool to profile Mozilla code.</dd> + <dt><a href="/en/Performance/Profiling_with_Xperf" title="en/Performance/Profiling with Xperf">Profiling with Xperf</a></dt> + <dd>How to use Microsoft's Xperf tool to profile Mozilla code.</dd> + <dt><a href="/en-US/docs/Performance/Profiling_with_Concurrency_Visualizer" title="en/Performance/Profiling with Concurrency Visualizer">Profiling with Concurrency Visualizer</a></dt> + <dd>How to use Visual Studio's Concurrency Visualizer tool to profile Mozilla code.</dd> + <dt><a href="/en/Performance/Profiling_with_Zoom" title="en/Performance/Profiling with Zoom">Profiling with Zoom</a></dt> + <dd>Zoom is a profiler for Linux done by the people who made Shark</dd> + <dt><a href="/en/Performance/Measuring_performance_using_the_PerfMeasurement.jsm_code_module" title="en/Performance/Measuring performance using the PerfMeasurement.jsm code module">Measuring performance using the PerfMeasurement.jsm code module</a> {{ gecko_minversion_inline("2.0") }}</dt> + <dd>Using <a href="/en/JavaScript_code_modules/PerfMeasurement.jsm" title="en/JavaScript code modules/PerfMeasurement.jsm"><code>PerfMeasurement.jsm</code></a> to measure performance data in your JavaScript code.</dd> + <dt><a href="/en-US/docs/Performance/Adding_a_new_Telemetry_probe" title="https://developer.mozilla.org/en-US/docs/Performance/Adding_a_new_Telemetry_probe">Adding a new Telemetry probe</a></dt> + <dd>Information on how to add a new measurement to the Telemetry performance-reporting system</dd> + <dt><a href="/en/Performance/Profiling_JavaScript_with_Shark" title="en/Performance/Profiling JavaScript with Shark">Profiling JavaScript with Shark</a> (obsolete - replaced by Instruments)</dt> + <dd>How to use the Mac OS X Shark profiler to profile JavaScript code in Firefox 3.5 or later.</dd> + <dt><a href="/en/Performance/Profiling_with_Shark" title="en/Performance/Profiling with Shark">Profiling with Shark</a> (obsolete - replaced by Instruments)</dt> + <dd>How to use Apple's Shark tool to profile Mozilla code.</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/Investigating_CSS_Performance">Investigating CSS Performance</a></dt> + <dd>How to figure out why restyle is taking so long</dd> + </dl> + + <h3 id="Power_profiling">Power profiling</h3> + + <dl> + <dt><a href="/en-US/docs/Mozilla/Performance/Power_profiling_overview">Power profiling overview</a></dt> + <dd>This page provides an overview of relevant information, including details about hardware, what can be measured, and recommended approaches. It should be the starting point for anybody new to power profiling.</dd> + <dt><code><a href="/en-US/docs/Mozilla/Performance/tools_power_rapl">tools/power/rapl</a></code> (Mac, Linux)</dt> + <dd><code>tools/power/rapl</code> is a command-line utility in the Mozilla codebase that uses the Intel RAPL interface to gather direct power estimates for the package, cores, GPU and memory.</dd> + <dt><code><a href="/en-US/docs/Mozilla/Performance/powermetrics">powermetrics</a></code> (Mac-only)</dt> + <dd><code>powermetrics</code> is a command-line utility that gathers and displays a wide range of global and per-process measurements, including CPU usage, GPU usage, and various wakeups frequencies.</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/TimerFirings_logging">TimerFirings logging</a> (All platforms)</dt> + <dd>TimerFirings logging is a built-in logging mechanism that prints data on every time fired.</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/Activity_Monitor_and_top">Activity Monitor, Battery Status Menu and <code>top</code></a> (Mac-only)</dt> + <dd>The battery status menu, Activity Monitor and <code>top</code> are three related Mac tools that have major flaws but often consulted by users, and so are worth understanding.</dd> + <dt><a href="/en-US/docs/Mozilla/Performance/Intel_Power_Gadget">Intel Power Gadget</a> (Windows, Mac, Linux)</dt> + <dd>Intel Power Gadget provides real-time graphs for package and processor RAPL estimates. It also provides an API through which those estimates can be obtained.</dd> + <dt><code><a href="/en-US/docs/Mozilla/Performance/perf">perf</a></code> (Linux-only)</dt> + <dd><code>perf</code> is a powerful command-line utility that can measure many different things, including energy estimates and high-context measurements of things such as wakeups.</dd> + <dt><code><a href="/en-US/docs/Mozilla/Performance/turbostat">turbostat</a></code> (Linux-only)</dt> + <dd><code>turbostat</code> is a command-line utility that gathers and displays various power-related measurements, with a focus on per-CPU measurements such as frequencies and C-states.</dd> + <dt><code><a href="https://01.org/powertop">powertop</a></code> (Linux-only)</dt> + <dd><code>powertop</code> is an interactive command-line utility that gathers and displays various power-related measurements.</dd> + </dl> + + <h3 id="Related_Topics">Related Topics</h3> + + <dl> + <dd><a href="/en/JavaScript" title="en/JavaScript">JavaScript</a>, <a href="/en/XPCOM" title="en/XPCOM">XPCOM</a>, <a href="/En/Developer_Guide" title="en/Developing_Mozilla">Developing Mozilla</a>, <a href="/en/Extensions" title="en/Extensions">Extensions</a>, <a href="/en/Addons" title="en/Addons">Addons</a></dd> + </dl> + </td> + </tr> + </tbody> +</table> + +<p> </p> |