{"id":194,"date":"2021-07-08T08:32:26","date_gmt":"2021-07-08T15:32:26","guid":{"rendered":"https:\/\/blog.mozilla.org\/performance\/?p=194"},"modified":"2021-07-09T09:03:42","modified_gmt":"2021-07-09T16:03:42","slug":"performance-tools-newsletter-h1-2021","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/performance\/2021\/07\/08\/performance-tools-newsletter-h1-2021\/","title":{"rendered":"Performance Tools Newsletter (H1 2021)"},"content":{"rendered":"

As the Perf-Tools team, we are responsible for the Firefox Profiler<\/a>. This tool is built directly into Firefox to understand the program runtime and analyze it to make it faster. If you are not familiar with it, I would recommend looking at our user documentation<\/a>.<\/p>\n

If you are curious about the profiler but not sure how to get to know it, I\u2019ve also given a FOSDEM talk<\/a> about using the Firefox Profiler for web performance analysis this year. If you are new to this tool, you can check it out there.<\/p>\n

During our talks with the people who use the Firefox Profiler frequently, we realized that new features can be too subtle to notice or easily overlooked. So we’ve decided to prepare this newsletter to let you know about the new features and the improvements that we\u2019ve made in the past 6 months. That way, you can continue to use it to its full potential!<\/p>\n

Table of Contents<\/h2>\n
    \n
  1. New features<\/a>\n
      \n
    1. Enabled the new profiler recording panel in Dev Edition<\/a><\/li>\n
    2. Visualization of the CPU utilization<\/a><\/li>\n
    3. Sample graph to show the samples\u2019 position in the timeline<\/a><\/li>\n
    4. Delete button on the profile viewer page<\/a><\/li>\n
    5. Stacks now include the category color of each stack frame<\/a><\/li>\n
    6. Profiler Rust API for thread registration has landed<\/a><\/li>\n
    7. Firefox Profiler Analysis UI is now internationalized<\/a><\/li>\n
    8. Screenshots are now visible while selecting a time range<\/a><\/li>\n
    9. Android Trace format support<\/a><\/li>\n
    10. \u201cProfiler\u201d category showing the profiler overhead<\/a><\/li>\n
    11. \u201cShow all tracks\u201d button in the timeline tracks context menu<\/a><\/li>\n<\/ol>\n<\/li>\n
    12. Improvements<\/a>\n
        \n
      1. Better network markers<\/a><\/li>\n
      2. Better stack walking around JIT<\/a><\/li>\n
      3. Better marker context menu<\/a><\/li>\n
      4. Marker improvements<\/a>\n
          \n
        1. New markers<\/a><\/li>\n
        2. Fixes & Improvements<\/a><\/li>\n<\/ol>\n<\/li>\n
        3. Capturing a stack and adding category support for the JavaScript ChromeUtils.addProfilerMarker<\/code> API<\/a><\/li>\n
        4. Tooltips in the network track<\/a><\/li>\n
        5. Made the Profile Info button more explicit<\/a><\/li>\n
        6. Android device information inside the Profile Info panel<\/a><\/li>\n
        7. Zip file viewer now automatically expands all the children<\/a><\/li>\n
        8. New label frames for XPIDL method\/getter\/setter calls<\/a><\/li>\n
        9. Profiler buffer memory is no longer counted in the profiler memory tracks<\/a><\/li>\n
        10. Improved accessibility in the Network Chart<\/a><\/li>\n
        11. Removed many MOZ_GECKO_PROFILER ifdefs<\/a><\/li>\n<\/ol>\n<\/li>\n
        12. What\u2019s next?<\/a><\/li>\n
        13. Conclusion<\/a><\/li>\n<\/ol>\n

          So, let\u2019s get started with the new features.<\/p>\n

          New features<\/h2>\n

          Enabled the new profiler recording panel in Dev Edition<\/h3>\n

          In the DevTools panel, we still had the old performance tab. That tool was pretty old and not very well maintained for a while. The new Firefox Profiler is a lot more comprehensive compared to the old tool. We aim to make it the new default one. We\u2019ve hit a big milestone and enabled it in the Firefox Dev Edition. We are hoping to get rid of the old panel soon. Thanks to Nicolas Chevobbe and Julian Descottes from the DevTools team for helping out on this!<\/p>\n

          Visualization of the CPU utilization<\/h3>\n

          Previously, the height of the activity graph (the graph in the pictures) wasn’t directly tied to the actual amount of work done: We were setting the height to 100% when we saw a non-idle sample there, and then applying some smoothing. But now, we collect the CPU usage information from Firefox and then draw the height of this graph to match the CPU usage of this thread. This allows our users to see which part of the thread is using more CPU and which part of the thread is using less. This is important because our users were thinking that the height actually meant CPU usage already, but it wasn\u2019t the case before. So, it\u2019s good to match our users\u2019 expectations in this case.<\/p>\n

          This new implementation also gives us information about the places where the Firefox is unresponsive but the thread is not using any CPU. In this case, it can mean that the thread is blocked.<\/p>\n

          When the graph height is not so high, except waiting for another thread, it can also mean that, either the thread is waiting on disk to write\/read a lot, or the whole system is working on a heavy task and not giving Firefox enough CPU time to run.. Previously, it wasn\u2019t possible to figure these cases out, but thanks to the CPU usage information, we can now understand it by looking at a profile.<\/p>\n

          Here are two example profiles. Both are from a startup of Firefox, but the first one is a warm startup, whereas the second one is a cold startup. You will notice easily that the graph height on the cold startup is a lot lower compared to the warm one. This is because on cold startups, we are reading a lot of data from the disk, and the reference laptop we used to capture these profiles has a slow disk:<\/p>\n