One more thing: implementing the jankometer is relatively easy and would help you track this down. See r20130.
On Mon, Aug 31, 2009 at 9:10 AM, Amanda Walker<[email protected]> wrote: > Great writeup. There's definitely too much going on in the UI thread. Even > after the page paints, I'm seeing multi-second pauses while additional stuff > comes in, where the browser process is unresponsive (example: iGoogle with a > bunch of gadgets). It's not clear to me why any http resource loading is on > the main thread at all... > --Amanda > > On Mon, Aug 31, 2009 at 11: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. >> >> Mark >> >> > > > > -- > "Portability is generally the result of advance planning rather than trench > warfare involving #ifdef" -- Henry Spencer (1992) > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
