DevTools/Performance

< DevTools
Revision as of 17:19, 20 September 2016 by Gregtatum (talk | contribs) (Updating team header)

Team

Current Team fitzgen, gregtatum
Previous Members jsantell, vporof (moved to Project Tofino, but are still available for questions)
Product Management
SpiderMonkey Liason shu
Gecko Layout Liason
Mailing Group dev-developer-tools

Meetings

Meetings Time, Timezone, Location
Weekly Updates (will be changed after Whistler) Thursday, 8:30am PST, Jordan Santell's vidyo room

Overview

DevTools' Performance Tools are a set of tools designed to identify, locate and resolve jank and responsiveness issues in web applications, FxOS apps, and Firefox itself. There are currently three main views for inspecting sampling and marker data (waterfall, call tree, flame chart).

Some experimental views are currently available optionally, such as allocation views, and the JIT Optimizations view.

Goals

  • Provide insight to issues related to performance in web applications
  • Provide insight to issues related to performance in FxOS Apps
  • Offer guidance and suggestions on fixing performance problem areas
  • Approach feature parity with Gecko Profiler for layout, rendering issues (meta bug)
  • A consolidated area for any team on Gecko to implement their own view to solve specific performance issues

Internals

There are two main sets of data used in a recording profile -- marker data and profiler data.

Profiler data is the same information as the previous Profiler tool and that the Gecko Profiler uses. This samples the JS executing at a specified rate, and also returns painting, layout and marker data that currently only the Gecko Profiler uses. This tool only uses the sampling information, which lets us calculate cost and timing of functions in JS, as well as what JIT optimizations were used for JS.

Marker data is currently based on ProfileTimelineMarkers. Gecko Profiler uses the underlying profiler to generate markers, whereas Performance Tools uses these ProfileTimelineMarkers, which are emitted via docshell in realtime, rather than fetched on demand. The FxOS Performance team uses the same marker information from User Timing APIs, which this tool should most likely strive for.

These two data sources are merged together in a final recording, with waterfall view using marker data, and the call tree and flame graph using profiler data. We also use Debugger.Memory information to collect allocation information to track down instances where allocation pressure causes jank.

Initiatives

Meta Bugs


Resources

Components