On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai<m...@chromium.org> wrote:
>
> 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.
Go Mark go! This is definitely one of my annoyances on Mac.
- Pam
>
> Mark
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
