Hello! As we continue our relentless focus on improving Firefox performance, I would like to call your attention to some related improvements in our tools that occurred over the last few months.
First of all, the performance tools team and the automation team worked together to make perf.html <https://perf-html.io> and treeherder <https://treeherder.mozilla.org/> more integrated. The result is that now perf.html can load zip files from try with Talos profiles and display them, while treeherder now displays links to perf.html in Talos jobs that record a profile. Performance sheriffs have started including links to these profiles in Talos regression reports, but you can also get them on try by running |./mach try fuzzy --talos-profile| (here <https://treeherder.mozilla.org/#/jobs?repo=try&revision=83e5926195a64bf83c8173cd042f795b073a6cea&selectedJob=174850360> is an example). We encourage everyone to generate profiles before landing their changes, to make sure Firefox performance doesn't regress. A good strategy is to generate two profiles, one before landing the change and one after. When you then open them side by side, it will be much easier to see what impact your changes had. The Gecko Profiler itself has received some notable improvements (apart from the regular speedups and bug fixes): - There is a new Flame Graph* visualization that provides a summary view of which stack frames consumed the most CPU. What you are looking for here is long dark nodes: the length indicates the relative percentage in the profile and the darker colors indicate higher self-time (with a different hue for native vs. JS frames). This is different from the similar Stack Chart view that gives you a time-based view of code execution. Both have their advantages, so combining them can lead to better insights. Summary views can also be very valuable when comparing profiles. - The profiler now collects network request information that can be seen in the Marker Chart. This visualization is a first rough cut; expect more intuitive views and better filtering there. But you can already use it to see when Firefox is blocked on a network request and how network loads correlate with page rendering. If you encounter any problems while using the profiler, please file them in Core::Gecko Profiler <https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Gecko%20Profiler> (for backend bugs) or open an issue <https://github.com/devtools-html/perf.html/issues/> on GitHub for UI improvements. And if you have any feedback on the treeherder/profiler integration, don't hesitate to drop me a note. Happy profiling! Panos *: you can learn more about flame graphs from their inventor Brendan Gregg at http://www.brendangregg.com/flamegraphs.html _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
