On Mon, Aug 31, 2009 at 9:17 AM, Brett Wilson<[email protected]> wrote: > On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai<[email protected]> 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. > > Interesting. > > One of these days, I need to finish my intern's summer project (he had > to leave early). It was a rewrite of thumbnail storage so we only > store the thumbnails for the new tab page, rather than in the history > system for each day. > > One thing I've thought of lately is to store the actual new tab items > in this same database. This way, we don't have to wait for history to > load (>10MB) and we don't have to do a complex query over that history > data to get the new tab page data.
By "items" I mean the URLs, titles, and ordering of the stuff on the new tab page, not just thumbnails. > Your post makes me wonder if this new "New Tab Page Database" can live > on the I/O thread. It will actually run the DB operations on yet > another thread, but we wouldn't have to go through the UI thread. > > Old way: I/O thread -> UI thread -> History thread -> UI thread -> I/O thread. > New way: I/O thread -> DB thread -> I/O thread The extra work on the DB thread only has to be done once, too. The new system caches the results so can respond immediately to new requests without querying the database. The current system has no caching. > There's no reason this object needs to live on the UI thread, so the > only problem would be plumbing the requests so it gets served properly > (though this might actually be kind of hard). Brett --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
