{"id":279,"date":"2021-11-15T13:57:18","date_gmt":"2021-11-15T21:57:18","guid":{"rendered":"https:\/\/blog.mozilla.org\/performance\/?p=279"},"modified":"2022-02-10T12:46:26","modified_gmt":"2022-02-10T20:46:26","slug":"performance-tools-newsletter-q3-2021","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/performance\/2021\/11\/15\/performance-tools-newsletter-q3-2021\/","title":{"rendered":"Performance Tools Newsletter (Q3 2021)"},"content":{"rendered":"

As the Perf-Tools team, we are responsible for the Firefox Profiler<\/a>. This newsletter gives an overview of the new features and improvements we\u2019ve done in Q3 2021.<\/p>\n

This is our second newsletter and you can find the first one here<\/a> which was about the H1 2021. With this newsletter, we wanted to focus on only Q3, so it would be less crowded and you can see the new features and improvements easily. I hope you enjoy the work that we\u2019ve done this quarter.<\/p>\n

Let\u2019s get started with the highlights.<\/p>\n

Network marker Improvements<\/h2>\n

We had network markers for a while and we had both a network track in the timeline and a network chart in the bottom panel. It was working fine for a while but it was lacking some functionalities. Also, we had some correctness issues around the markers, like sometimes we were missing some network markers. We\u2019ve worked on this task to improve both the Firefox Profiler analysis page and also the correctness of the values in the back-end.
\nHere are some of the things that we\u2019ve done:<\/p>\n

Highlight network markers in both the timeline and the network chart<\/h3>\n

Previously, network markers in the timeline and network chart were independent. When you interacted with one, it wasn\u2019t changing the other one. After this work, when you hover over a network marker, the same marker in the other part will be highlighted. Here\u2019s an example:<\/p>\n

\nhttps:\/\/blog.mozilla.org\/performance\/files\/2021\/11\/profiler-network-marker-hover.mov<\/a><\/video><\/div>\n

 <\/p>\n

Clicking a request in the network track selects the right line in the network chart<\/h3>\n

Previously, clicking on a network track wasn\u2019t doing anything. With this work, if you click on a network request in the network track in the timeline, it will automatically select the network marker in the network chart. It is helpful for quickly finding the network request you are looking for.<\/p>\n

New context menu in the network track<\/h3>\n

We have a context menu for the network chart in the bottom panel, but we didn\u2019t have one in the timeline network tracks. We\u2019ve added the context menu to the network tracks now and they can be used as the same. We are hoping that with this and other network track works, network track will be a lot more useful.<\/p>\n

\"Picture<\/p>\n

Display network markers in the marker chart<\/h3>\n

We\u2019ve started to show the network markers in the marker chart as well. It could be helpful when you are also looking for other markers and want to align the network markers with them.<\/p>\n

\"Example<\/p>\n

Support for network requests cancellations<\/h3>\n

This is one of the improvements that we made in the back-end to make the data more consistent and accurate. Firefox profiler didn\u2019t support the network request cancellations on service workers before. Now, you can see if a network request is being canceled and when.<\/p>\n

Profiling overhead reductions<\/h2>\n

Reducing the overhead of profiling Firefox sleeping threads<\/h3>\n

Previously, we were doing some costly operations for sampling even when a thread is idle. With this work, we\u2019ve reduced the overhead of profiling the sleeping thread dramatically. I\u2019m not going to get into the details of this improvement since our colleague Gerald Squelart wrote a great blog post about it already. You can take a look at it here if you are curious about the optimization he came up with and the implementation details. <\/a><\/p>\n

Reducing the overhead of Firefox Profiler recording by reducing mutex lockings<\/h3>\n

Firefox Profiler has an internal mutex inside of it. It is being used so other threads can modify the same data without any data loss or data race. But this mutex brings some overhead because when two threads need to add a marker at the same time, they both need to acquire the mutex lock. In that case, one of them had to wait for the other one. And this was bringing some overhead because of this mutex lock waiting time.
\nWith this work, we\u2019ve removed the need for mutexes from lots of places, including most importantly from marker recording sites.<\/p>\n

Rust API for Firefox Profiler<\/h2>\n

Firefox Profiler has some APIs for various languages like C++, JavaScript, and Java\/Kotlin inside the mozilla-central codebase. We also had some hacks around the Rust codebases, but they were added for each Rust project when they were needed and we had lots of code duplication because of it. Also, they weren\u2019t maintained by the Firefox Profiler team and they were prone to misuse. With this work, we\u2019ve created a canonical Rust API for the Firefox Profiler and removed all the code duplications\/hacks around the codebase.<\/p>\n

We have three main functionalities with this API:<\/p>\n

    \n
  1. Registering Rust threads:\n
      \n
    1. With this functionality, you can register a Rust thread, so Firefox Profiler can find it and possibly profile it. It\u2019s good to keep in mind that only registering a thread will not make it appear in the profile data. In addition, you need to add it to the \u201cThreads\u201d filter in about:profiling.
      \nWe had some hacks around the thread registration for Servo and WebRender threads, so we could profile them. But they were duplicated and were using the raw FFI bindings.<\/li>\n<\/ol>\n<\/li>\n
    2. Adding stack frame labels:\n
        \n
      1. Stack frame labels are useful for annotating a part of the call stack with a category. The category will appear in the various places on the Firefox Profiler analysis page like timeline, call tree tab, flame graph tab, etc.<\/li>\n<\/ol>\n<\/li>\n
      2. Adding profiler markers:\n
          \n
        1. Markers are packets of arbitrary data that are added to a profile by the Firefox code, usually to indicate something important happening at a point in time, or during an interval of time.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

          We also have documentation about this API in the Firefox source docs<\/a>. Please take a look at it for more details and examples if you are interested. Also, we are going to be writing a blog post about this API soon. Stay tuned!<\/p>\n

          Show the eTLD+1 of Isolated Web Content Processes as their track name<\/h2>\n

          The timeline of the Firefox Profiler analysis page is very crucial to finding the data we are looking for. Inside the timeline, we have various registered processes and threads that Firefox had during the profiling session. When we have lots of tracks in the timeline, it might be hard to figure out which track we are interested in.<\/p>\n

          Previously, all the web content processes had a single name called \u201cWeb Content\u201d or \u201cIsolated Web Content\u201d (when Fission is enabled<\/a>). This is not explicit when it comes to figuring out a specific tab. This was implemented this way before because there wasn\u2019t a way to determine the tab URL for a specific \u201cWeb Content\u201d process. But with Fission, we precisely know which process belongs to which eTLD+1. After this work, we\u2019ve started to show their eTLD+1 as their track name. This way, it will be a lot easier to determine which track you are looking for.<\/p>\n

          Here\u2019s an example of before and after:<\/p>\n

          \"Before

          Before<\/p><\/div>\n

          \"After

          After<\/p><\/div>\n

          Linux perf importer improvements<\/h2>\n

          Firefox Profiler had Linux perf support for quite some time. We have this documentation about how to profile with it and how to import it.
          \nOur contributor, Mark Hansen, made some great improvements on the Linux perf support to make it even better. Here are the things Mark Hansen improved:<\/p>\n