![](/style/images/good.png)
![](/style/images/bad.png)
Improving DevTools startup time | Web | Google Developers
source link: https://developers.google.com/web/updates/2021/02/faster-devtools-startup
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
![Maksim Sadym](https://developers.google.com/web/images/contributors/sadym.jpg)
Interested in helping improve DevTools? Sign up to participate in Google User Research here.
DevTools startup now is ~13% faster 🎉 (from 11.2s down to 10s).
TL;DR; The result is achieved by removing a redundant serialization.
Overview
While DevTools is starting up, it needs to make some calls to the V8 JavaScript engine.
The mechanism Chromium uses to send DevTools commands to V8 (and for IPC in general) is called mojo
. My teammates Benedikt Meurer and Sigurd Schneider discovered an inefficiency while working on another task, and came up with an idea to improve the process by removing two redundant steps in how these messages are sent and received.
Let us dive into how the mojo
mechanism works!
The mojo
mechanisms
There is a mojo command EvaluateScript
which runs the JS command. It serializes the whole JS command including the arguments
into a string of JavaScript source code that can be eval()
. As you might imagine, these strings can become quite long and expensive. After the command is received by V8, these strings of JavaScript code are deserialized before running. This process of serializing and deserializing for every single message creates significant overhead.
Benedikt Meurer realised that serialisation and deserialisation of the arguments
is quite expensive, and that the whole "Serialize JS command to JS string" and "Deserialize JS string" steps are redundant and can be skipped.
Technical details: RenderFrameHostImpl::ExecuteJavaScript
How we improved
We introduced another mojo API method which allows us to pass the object name, the method to be called, and the list of arguments directly, instead of having to create the string of JavaScript source code. This allows us to skip serialization & deserialization, and removes the need to parse the JavaScript code.
For technical details on how we implemented this optimization, consult these two patches:
Impact
To measure the effectiveness of the change, we ran some measurements comparing Chromium revisions cb971089a058 and 4f213b39d581 (before and after the change).
For both revisions, we ran the following scenario 5 times:
- Record trace using
chrome://tracing
- Open DevTools-on-DevTools
- Get the recorded
CrRendererMain
trace and compare the V8-specific metrics.
Based on these experiments, DevTools opens ~13% faster (from 11.2s down to 10s) with the optimization.
Hightlights, CPU durations
Full tracing metrics comparison table
As a result, DevTools opens and works faster with less CPU usage. 🎉
Feedback
To discuss the new features and changes in this post, or anything else related to DevTools:
- File definite bug reports and feature requests at Chromium Bugs.
- Discuss possible features, changes, and bugs on the Mailing List.
- Get help on how to use DevTools on Stack Overflow.
- Tweet us at @ChromeDevTools.
- File bugs on this document in the Web Fundamentals repository.
Discover DevTools engineering content
Below is a list of everything that's been covered in the Chrome DevTools Engineering Blog series.
rss_feed Subscribe to our RSS or Atom feed and get the latest updates in your favorite feed reader!
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK