Chrome Tracing Episode 1: Starting anywhere2 minutes to read
I’ve been working on trace viewer for a good while now, and most of the time I’ve been enduring a deep sense of guilt that I don’t actually use the thing more.
So here it goes: I’m going to try my best to spend an hour every day or two using trace viewer to dig into how Chrome works, and write up the results here.
Given that I have no real idea where to start, I just picked a random site: my Github profile.
I’ll be doing all of the tracing in Chrome Canary, just to make sure I have the freshest features available.
Also, just because I know that plugins can have a performance impact that I don’t care to learn more about at the current moment, I’m going to make sure that I do all of my tracing from incognito mode, and with only a single browsing tab open for now (with a second tab open for tracing purposes).
So here it goes.
I started out by navigating to chrome://tracing and clicked the “Record” button. I then selected the “Rendering” settings (I didn’t think I could manually pick any better ones), and clicked “Record”. I opened a new tab and went to the page (https://github.com/zeptonaut), went back to my tracing tab, and clicked “Stop”. Now comes time for investigation.
This is what I’m greeted with:
In the trace, it looks like a flurry of activity happens right after 6 seconds: I’m going to guess that’s when I actually started loading the Github page.
Zooming in on the “NetLog” track (option+cmd+scroll), it looks like this suspicion is confirmed. Right around 6.3s, you can see:
(P.S. Wow! You need good eyesight to see that little Netlog bar. We should fix that.)
Scrolling down a bunch of tracks to the Github page renderer, it looks like the real work starts about 20-30ms earlier:
That first blue little slice is titled
ChannelReader::DispatchInputData. I’m guessing that’s important, because it looks like that’s the first thing that happens. Well, what the heck is a
ChannelReader, and what does it mean to
Looking up ChannelReader on code search seems to show that
ChannelReader is just a way to read pipes between processes. It looks like it has something to do with IPCs (inter-process calls). Maybe that’s not what we were after.
After that is
MessageLoop::RunTask. I know that the
MessageLoop is just the main loop that runs on each thread that constantly checks for and executes new tasks. That’s not what I want, either: I really want the first interesting piece of work that has to do with me navigating.
Well… I give up for today. Maybe I’ll have better luck tomorrow finding something.