I spent a chunk of last week looking at the new tab page performance
on startup on the Mac. I found that the renderer was waiting on data
from the browser process for what seemed like far too long. The key
to this problem is that resource requests for the new tab page are
funneled through the browser process' main (UI) thread. At least on
the Mac, when a new tab is being created or while the application is
starting up, there's a lot of contention for the UI thread: the window
is being drawn and there might be animations or other effects, not to
mention that infernal throbber.
The good news is that turning off the tab strip's Core Animation layer
improves this, as well as many other things. A patch to do this just
landed again at r24881 (on the third try). In my experiments, this
reduced the time from when the renderer requests the new tab page to
the time that all of the resources are present in the renderer from
between 1-3 seconds to just a hair over 300ms. This is a huge
improvement.
I still think that 300ms is too long, though, especially when you
consider that this is not the time from launch, but the time from the
renderer's request, which itself can come as much as 300ms after
launch.
I'm experimenting with a change that lets the new tab HTML and CSS be
served directly from the browser's IO thread instead of the UI thread.
Since these tasks require profile and theme access, the approach is
to build up the HTML and CSS early, on the UI thread where such access
is permitted, and cache them. When a request for the HTML or CSS
comes in, the browser can then service them entirely on the IO thread.
This gets the data into the renderer almost immediately after it's
requested, so that the renderer is able to fully lay out the new tab
page without having to wait for the browser to do things like draw the
new tab. Additional resource requests, such as thumbnails and
favicons, are still being served from the UI thread. Based on my
experiments, this shouldn't be a problem: the renderer isn't ready to
receive these until it's done with layout based on the HTML and CSS,
and once it reaches that point, the browser should be done with heavy
UI tasks and there shouldn't be much contention for its main loop. It
might ultimately be better to be able to serve all new tab requests
from a non-UI thread in the browser, but that could mean additional
caching.
This change improves new tab page performance by about 65ms on my
laptop in release mode. Now we're down to 240. Great. What else can
we do?
Well, that annoying throbber is still chewing up time, causing some
amount of UI loop contention while the images, thumbnails, and icons
are fetched. Windows and Linux don't have a throbber for the new tab
page. We shouldn't either. Excellent, now we're down to 200ms. It's
still high, but it's reasonable. It's a perceptible improvement from
the 300ms we started with.
What else can we do? One thing that's begging for improvement based
on my timings is the renderer startup delay. We don't bother starting
up a renderer until about 200ms after launch, and it takes the
renderer 70ms from that point to reach its main loop. I bet that if
we did renderer startup much earlier, we'd have one warm and ready to
go by the time we needed it. This doesn't have to be
startup-specific, we could always maintain a spare renderer in the
pool (within reason) so that we're not caught twiddling our thumbs
waiting for the one we just launched.
Mark
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
