{"id":338,"date":"2022-02-15T05:12:26","date_gmt":"2022-02-15T13:12:26","guid":{"rendered":"https:\/\/blog.mozilla.org\/performance\/?p=338"},"modified":"2022-02-15T05:12:26","modified_gmt":"2022-02-15T13:12:26","slug":"performance-tools-newsletter-q4-2021","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/performance\/2022\/02\/15\/performance-tools-newsletter-q4-2021\/","title":{"rendered":"Performance Tools Newsletter (Q4 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 Q4 2021.<\/p>\n

You can find the previous newsletter here<\/a> which was about the Q3 2021. With this newsletter, I will be writing about the things we\u2019ve done in the Q4 2021. I hope you\u2019ll enjoy the work that we\u2019ve done this quarter.<\/p>\n

Here are some highlights.<\/p>\n

Source view for C++ \/ Rust code<\/h2>\n

Firefox Profiler is a great tool for providing performance analysis in relation to how long each function took. However, once a slow function is found, it is important to be able to dive in right away and figure out what is going on. Previously, it wasn\u2019t possible to do this, but with this work, now you can see the source of C++ and Rust code in a view. All you need to do is to double click on a frame on Call Tree or Flame Graph panels. A new panel at the bottom will appear and show you the function you clicked. Here\u2019s an example screenshot:<\/p>\n

\"Firefox<\/a>Also, here\u2019s a link to an example profile if you are curious<\/a>. This was tremendous work and it\u2019s great that this can be used by our users now. I would like to thank Markus Stange especially for implementing this.<\/p>\n

Support for inline call stacks<\/h2>\n

Whenever the compiler was inlining a function call away, we were completely losing information about the fact that it was that call that took up time, because we didn\u2019t have inline stacks support. We only could see the time in the parent call node. This meant that we weren\u2019t displaying the correct information to our users. Now with this work, we are not lying about the functions that take time anymore. It also displays an inline badge on the left side of a sample, so you can see that this function was inlined. Here\u2019s an example profile link if you are curious<\/a>. Currently it works for only local builds, but in the future it will work on official release channels as well.<\/p>\n

\"Inline<\/a>One click profiling in about:processes page<\/h2>\n

In the about:processes page, it\u2019s possible to see all the Firefox processes and their information. In addition to that, now it\u2019s possible to profile directly through this page with only one click. When you hover over a process, a profile button will appear at the right side of the process name. All you have to do is to click on this button and it will start profiling this specific process for 5 seconds. Once it\u2019s finished, it will open the profiler analysis UI.<\/p>\n

\"A<\/a>Read profile buffer once to output all samples and markers<\/h2>\n

This was one of the performance improvements that we\u2019ve worked on the back-end this quarter. Previously, we were reading the buffer twice for every thread (one for samples and one for markers). Now we are only doing this once and outputting all the threads. This improvement brings ~5x speed up during the profile serialization!<\/p>\n

Localize the presets of Profiler capturing UI<\/h2>\n

We are done with localizing our profile analysis UI and we were also done with most of our profile capturing UI. Presets belong to the capturing UI for setting the relevant settings quickly. We\u2019ve now finished the localization work for them as well and we are completely done with the profile capturing UI as well!<\/p>\n

\"Image<\/a>Better front-end for experience for profiles with many threads<\/h2>\n

With Fission, we have more and more processes and threads in Firefox. Because of this, when a user profiles Firefox, they see a lot of threads as well. It\u2019s both hard to navigate with lots of threads and it\u2019s slower to load and use. To fix these issues we worked on various things:<\/p>\n

UI improvements related to track finding<\/h3>\n

Add a search filter to the track context menu<\/h4>\n

It\u2019s hard to find the thread you are looking for when there are a lot of threads. To make this easier, we added a search filter in the main tracks context menu. This way, you can search and find the thread you are looking for easily.<\/p>\n

Make it easier to use with a keyboard<\/h4>\n

Previously, our context menu wasn\u2019t really keyboard friendly. It was resetting the selected state every time the user pressed enter. That was really annoying because it was making it hard to repetitively show or hide some threads. This task was a bit harder than expected because we were using a third party library for the context menu and it wasn\u2019t maintained anymore for some time. That\u2019s why we forked that library and fixed the issues ourselves.<\/p>\n

Move the location of the main track context menu to the left side of the timeline.<\/h4>\n

Our tracks menu button was on the right side of the graph type radio buttons. That wasn\u2019t really\u00a0 visible and our users actually expected it to be on the top of the tracks. So, we moved the track menu button to the left side where the tracks are.<\/p>\n

Add \u201cShow all tracks below\u201d button after filtering<\/h4>\n

When you filter some search queries, now \u201cShow all tracks below\u201d will appear and you can make all the search filtered tracks visible by clicking it.<\/p>\n

Here\u2019s you can see the things we changed related to tracks menu:<\/p>\n

\"An<\/a>Default visible thread list computation changes.<\/h3>\n

We\u2019ve changed how we compute the default visible threads when a profile first loads. Previously, it was possible to see a lot of threads in a big profile. Now we\u2019ve limited the visible threads to 15 and we started to get the most active threads among them.<\/p>\n

Performance improvements<\/h3>\n

Besides UX changes, it\u2019s also important to make sure that we can show many threads without becoming too slow. We\u2019ve worked on some performance improvements to guarantee that Firefox Profiler still works without a problem with many threads like removing costly getBoundingClientRect calls from canvases. There are still more improvements to be done in the timeline to improve the performance and we are still working on it.<\/p>\n

Profiling for all the threads<\/h2>\n

Sometimes it may be possible that you don\u2019t know which thread to profile or you are uncertain about it. In cases like that, it might be a good idea to profile all the threads. In the about:profiling page we have various features now that you can enable. Currently there are 3 options:<\/p>\n

    \n
  1. CPU Utilization – All Threads: For profiling CPU utilization values of all the threads<\/li>\n
  2. Periodic Sampling – All Threads: For sampling all the threads. Beware that it will increase the overhead significantly!<\/li>\n
  3. Markers – All Threads: For collecting markers from all the threads.<\/li>\n<\/ol>\n

    You can also combine these features to profile multiple of these values. But it\u2019s good to keep in mind that all of them will increase the overhead of profiling and you should use it at your own discretion.<\/p>\n

    Periodically discovering unregistered threads<\/h2>\n

    This is also another new feature we have in the about:profiling page. It will periodically discover all the unregistered threads and record their CPU utilization for them. For now, they show up as markers in the main thread, but they will eventually have better UI. Also it increases the overhead of profiling a lot, especially on Windows. So, be careful while using it.<\/p>\n

    Other improvements<\/h2>\n