This post has been republished via RSS; it originally appeared at: Microsoft Edge Blog.On the Microsoft Edge team, we spend a lot of time working with product teams across Microsoft to support them in building great web experiences, and jointly raising the bar for how these apps perform for everyone, whatever device they may use. In this post, we’ll review some new DevTools capabilities we have recently built in partnership with the Office Performance team, which enable concrete performance improvements in production web experiences. There are many ways to measure the complexity of a web app and its code base, but when it comes to performance, the following indicators tend to play an important role:
- The number of nodes in the DOM tree.
- The number of stylesheets and CSS rules in the document.
- The number of HTTP requests, and the total size of the transferred data on page load.
Reducing CPU sampling overhead by 95%Earlier this year, the Office team was investigating the launch performance of the PowerPoint web app, which uses multiple out-of-process iframes. While doing so, they noticed significant CPU usage overhead while recording profiles in the Performance tool of Edge DevTools. In fact, in some instances, DevTools was seemingly responsible for saturating an engineer’s 10 core CPU while profiling. Using Event Tracing for Windows (ETW), the team determined that this was due to the way the CPU profiler in Chromium (the browser engine which Edge is built on) was doing its sampling. In summary, it was using a busy waiting approach which meant constantly running code even while waiting for the next event. Under normal circumstances, the overhead would have been negligible, but with the many processes that PowerPoint used, it was starting to become a problem. By using a more accurate sleep timing method, the team was able to reduce the CPU sampling overhead by 95% and decrease the total CPU consumption from Edge by 71% while profiling. Of course, this helped the PowerPoint team investigate and improve the load performance of their app, but this also means that everyone using the Performance tool in DevTools (in Edge or any Chromium browser) now has a much better experience.
Simplified source maps everywhere you need themWe're also working to improve the quality and reliability of the Performance tool with better support for source maps. Source maps are used in DevTools to map your production code (often bundled and minified) back to your original source code. While source maps have been available in the Sources tool for a while, we’ve added support for them in the Performance and Memory tools too. The Performance tool now automatically shows un-minified function and file names, which makes investigating slowdowns in your apps a lot easier. On top of this, we've added support Azure Pipelines, which makes publishing source maps during your build process a lot simpler. You can now generate and publish your source maps to the symbol server and then securely retrieve them in DevTools. This makes getting source maps a lot easier in DevTools; all you need to do is either login to your Azure Active Directory from DevTools, or enter an ADO access token. Being able to see original function names in the Performance tool has already helped us many times. For example, it helped us spot several easy wins while investigating and improving the load time of PowerPoint. It would have been nearly impossible to find as many of these function calls as we did with a minified profile. When working on a complex codebase, there can be thousands of other minified functions calls in a performance profile, but seeing the original function names made it a lot easier to recognize bad patterns.
A slew of memory improvementsThe previous improvements were all about helping make apps faster to load and to run. But we also spend a lot of time making sure our apps have as small a memory footprint as possible. And again, we work together across teams, to invent and implement the tools that can make our lives easier. Here are some of the improvements we’ve made to the DevTools’ Memory tool that have helped us already, and that may be useful to you too:
- The Memory tool can now load much larger heap snapshot files: when memory gets out of control and a memory leak investigation is needed, it helps if the tool can deal with large amounts of data.
- We also made recording large heap snapshots much faster. Generating large heap snapshots that weigh over 1GB is now 70% to 86% faster.
- We made it possible to compare two heap snapshots by their retainer paths. For applications with a size and complexity that’s comparable to the Microsoft 365 web apps, this makes finding memory leaks much easier. You can now see what top level objects are growing in retained size.
- Navigating large memory heap snapshots is also easier now with the ability to filter snapshopts by node types.