Tools for Debugging Gecko Core

  • Revision slug: Performance/Debugging_a_Performance_Problem
  • Revision title: Debugging a Performance Problem
  • Revision id: 403241
  • Created:
  • Creator: bgirard
  • Is current revision? No
  • Comment

Revision Content

The first steps to understanding a performance problem is finding the area responsible and collecting information. If you haven't yet, (1) file a bug at this point you should do so now. At this point you may not know the component responsible for the performance problem so take your best guess and update it as your investigation progresses.

Before proceding try testing in against older releases of Firefox and against the up to date Nightly build.

This article will outline the tools and techniques you can use for debugging and performance. Each article is listed with a contact you can ask questions about this tool.

Built-in Profiler (BenWa)

General purpose profiler. Useful if you experience: Periodic hangs, slow JS scripts, want to know where the CPU time is being spent, what events are blocking the main thread, target profiling of certain areas.

For more information see: https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler

System Profiler (BenWa)

Prefer a system specific profiler if you're interested in C++ and cache behavior. Particularly VTune (Windows, license required), Instrument (XCode, free), perf (Linux). See: https://developer.mozilla.org/en-US/docs/Performance

API Trace (gw280)

A shim OpenGL library that interposes the OpenGL call that records them before sending them to the OpenGL driver. We can use this to trace the opengl calls to trace file that we can later pull from the device and replay it in the computer. This tool will let you replay the trace, looking at each frame and analyze the current rendering and analyzing the OpenGL frame. This tool is very useful at finding OpenGL state bugs.

Paint Flashing (BenWa)

Paint flashing will show which area of the screen are being drawn. In general, but subject to a ton of exception, if something isn't changing we shouldn't be redrawing them. Use paint flashing to see which area of the screen are being redrawn internaly. On desktop open the devtools windows and click on the paint brush icon in the bottom left. On mobile flip the preference 'nglayout.debug.paint_flashing'. For example when scrolling you expect to only see the side of the page being brought into view being repainted. Note on mobile we use a displayport to predraw outside the screen so paint flashing behavior is quite different there.

Execessive paint flashing can be caused by overpainting which indicates a layout bug. Particularly if every scroll or update causes the entire screen to flash or if css transformed elements are being repainted. See layers.force-active as well

layers.force-active

If paint flashing shows that the page performance is suffering from execussive flashing

LayerScope (Vlad)

Layer Borders (Nical)

Player2D (Bas)

MOZ_GL_DEBUG (bjacob)

Useful if: You have some rendering glitches when using OpenGL.

Use this tool to:

  • Find if the code uses an OpenGL context which isn't current.
  • Have syncronization problems
  • Want to find the exact call
  • Want to dump a log of the OpenGL functions called.

Layout Debugging

Dump Painting

Dump Render Frame

Build tricks

Rebuilding subdirectory with debugging (bjacob)

Disable code folding (bjacob)

GDB

Set commands breakpoint when debugging (bjacob)

moz_debug_childprocess / moz_debug_apps (kanru)

Revision Source

<p>The first steps to understanding a performance problem is finding the area responsible and collecting information. If you haven't yet, <strong>(1) file a bug</strong> at this point you should do so now. At this point you may not know the component responsible for the performance problem so take your best guess and update it as your investigation progresses.</p>
<p>Before proceding try testing in against older releases of Firefox and against the up to date Nightly build.</p>
<p>This article will outline the tools and techniques you can use for debugging and performance. Each article is listed with a contact you can ask questions about this tool.</p>
<h2 id="Built-in_Profiler_(BenWa)">Built-in Profiler (BenWa)</h2>
<p>General purpose profiler. Useful if you experience: Periodic hangs, slow JS scripts, want to know where the CPU time is being spent, what events are blocking the main thread, target profiling of certain areas.</p>
<p>For more information see: https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler</p>
<h2 id="System_Profiler_(BenWa)">System Profiler (BenWa)</h2>
<p>Prefer a system specific profiler if you're interested in C++ and cache behavior. Particularly VTune (Windows, license required), Instrument (XCode, free), perf (Linux). See: https://developer.mozilla.org/en-US/docs/Performance</p>
<h2 id="API_Trace_(gw280)">API Trace (gw280)</h2>
<p>A shim OpenGL library that interposes the OpenGL call that records them before sending them to the OpenGL driver. We can use this to trace the opengl calls to trace file that we can later pull from the device and replay it in the computer. This tool will let you replay the trace, looking at each frame and analyze the current rendering and analyzing the OpenGL frame. This tool is very useful at finding OpenGL state bugs.</p>
<h2 id="Paint_Flashing_(BenWa)">Paint Flashing (BenWa)</h2>
<p>Paint flashing will show which area of the screen are being drawn. In general, but subject to a ton of exception, if something isn't changing we shouldn't be redrawing them. Use paint flashing to see which area of the screen are being redrawn internaly. On desktop open the devtools windows and click on the paint brush icon in the bottom left. On mobile flip the preference 'nglayout.debug.paint_flashing'. For example when scrolling you expect to only see the side of the page being brought into view being repainted. Note on mobile we use a displayport to predraw outside the screen so paint flashing behavior is quite different there.</p>
<p>Execessive paint flashing can be caused by overpainting which indicates a layout bug. Particularly if every scroll or update causes the entire screen to flash or if css transformed elements are being repainted. See layers.force-active as well</p>
<h2>layers.force-active</h2>
<p>If paint flashing shows that the page performance is suffering from execussive flashing</p>
<h2 id="LayerScope_(Vlad)">LayerScope (Vlad)</h2>
<h2 id="Layer_Borders_(Nical)">Layer Borders (Nical)</h2>
<h2>Player2D (Bas)</h2>
<h2 id="MOZ_GL_DEBUG_(bjacob)">MOZ_GL_DEBUG (bjacob)</h2>
<p>Useful if: You have some rendering glitches when using OpenGL.</p>
<p>Use this tool to:</p>
<ul>
  <li>Find if the code uses an OpenGL context which isn't current.</li>
  <li>Have syncronization problems</li>
  <li>Want to find the exact call</li>
  <li>Want to dump a log of the OpenGL functions called.</li>
</ul>
<h2 id="Layout_Debugging">Layout Debugging</h2>
<h3 id="Dump_Painting">Dump Painting</h3>
<h3 id="Dump_Render_Frame">Dump Render Frame</h3>
<h2 id="Build_tricks">Build tricks</h2>
<h3 id="Rebuilding_subdirectory_with_debugging_(bjacob)">Rebuilding subdirectory with debugging (bjacob)</h3>
<h3 id="Disable_code_folding_(bjacob)">Disable code folding (bjacob)</h3>
<h2 id="GDB">GDB</h2>
<h3 id="Set_commands_breakpoint_when_debugging_(bjacob)">Set commands breakpoint when debugging (bjacob)</h3>
<h3 id="moz_debug_childprocess_.2F_moz_debug_apps_(kanru)">moz_debug_childprocess / moz_debug_apps (kanru)</h3>
Revert to this revision