[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
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 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. Mark -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@chromium.org wrote: 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 cache is in-memory only, right? That is, it's generated during startup? (In the past I've talked about caches but I'm worried that the NTP positioning will jump around due to stale caches, since the site ranking is based on day granularity. Though that could be considered a design flaw.) 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. Another option is for the browser push these resources into the NTP as it's being constructed. That is, textually append a script tag with the JSON blob of the NTP data at the bottom of the NTP HTML. That's how our translation templating works and it skips all the back-and-forth of requests. I believe the only reason it wasn't done that way originally was because we didn't have the necessary data generated in time, but your cache fixes it. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
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 Walkerama...@chromium.org 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 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. Mark -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
Amanda Walker 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... HTTP resource loading shouldn't be on the browser's main thread. This only applies to DOM UI resource loading, chrome: and chrome-internal:. That stuff gets funneled through the browser's main thread for things like profile and theme access. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@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. 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. 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
Evan Martin wrote: This cache is in-memory only, right? That is, it's generated during startup? (In the past I've talked about caches but I'm worried that the NTP positioning will jump around due to stale caches, since the site ranking is based on day granularity. Though that could be considered a design flaw.) Right now, I'm hanging a new method on NewTabHTMLSource to generate the data and store it in a member. I'm calling that from the NTHS constructor, and I'm doing the same thing for the CSS in DOMUIThemeSource. It seems that each occurrence of the New Tab Page gets its own NewTabHTMLSource and DOMUIThemeSource objects, so the cache should be scoped to a single instance of a New Tab Page. I haven't experimented with Reload or tried other things that might abuse the cache. Another option is for the browser push these resources into the NTP as it's being constructed. That is, textually append a script tag with the JSON blob of the NTP data at the bottom of the NTP HTML. That's how our translation templating works and it skips all the back-and-forth of requests. Yup, that would cover it too. Thanks for the suggestion. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 12:12 PM, Mark Mentovai m...@chromium.org wrote: HTTP resource loading shouldn't be on the browser's main thread. This only applies to DOM UI resource loading, chrome: and chrome-internal:. That stuff gets funneled through the browser's main thread for things like profile and theme access. OK, I'll rephrase: *something* is blocking the main thread (beachball cursor, can't scroll, etc.) for multiple seconds at a time for pages like iGoogle that require lots of HTTP requests. I've been assuming it's http fetching, since the status line says waiting for But if that's not it, something else is. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 9:17 AM, Mark Mentovaim...@chromium.org wrote: Evan Martin wrote: This cache is in-memory only, right? That is, it's generated during startup? (In the past I've talked about caches but I'm worried that the NTP positioning will jump around due to stale caches, since the site ranking is based on day granularity. Though that could be considered a design flaw.) Right now, I'm hanging a new method on NewTabHTMLSource to generate the data and store it in a member. I'm calling that from the NTHS constructor, and I'm doing the same thing for the CSS in DOMUIThemeSource. It seems that each occurrence of the New Tab Page gets its own NewTabHTMLSource and DOMUIThemeSource objects, so the cache should be scoped to a single instance of a New Tab Page. I haven't experimented with Reload or tried other things that might abuse the cache. The one that's easy to break is incognito: open one normal window, one incognito, try refreshing the NTP on both. Check that this actually works on trunk before you assume any breakage was introduced by you. ;) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 9:17 AM, Brett Wilsonbre...@chromium.org wrote: On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@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. 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
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess sh...@chromium.org wrote: On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@chromium.org wrote: 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. It might be interesting to have the IO thread tag messages with the time as they go by, and have the UI thread keep track of the distribution of times that messages spend enqueued. Then we can set goals around how fast IPCs get pulled off the queue. The IPC logging code already keeps track of message dispatch time (i.e. from when Send() was called until the message handler started executing) and processing time (i.e. how long the handler took). I don't know how much of the UI is implemented on Mac, but on Windows this was only a few hours to implement, and it'll give a lot of insight on which messages are backed up/taking a lot of time. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
jam: It's a good idea; we came to the same conclusion. I implemented the about:ipc UI as part of our performance focus last week. However, when I hooked it up, I noticed the logging itself was never fully ported from Windows; it uses a cross-process waitable event, but waitable_event_posix.cc isn't cross-process. So I'm working on that too. jrg On Mon, Aug 31, 2009 at 9:57 AM, John Abd-El-Malek j...@chromium.org wrote: On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess sh...@chromium.org wrote: On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@chromium.org wrote: 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. It might be interesting to have the IO thread tag messages with the time as they go by, and have the UI thread keep track of the distribution of times that messages spend enqueued. Then we can set goals around how fast IPCs get pulled off the queue. The IPC logging code already keeps track of message dispatch time (i.e. from when Send() was called until the message handler started executing) and processing time (i.e. how long the handler took). I don't know how much of the UI is implemented on Mac, but on Windows this was only a few hours to implement, and it'll give a lot of insight on which messages are backed up/taking a lot of time. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 4:50 PM, John Grabowski j...@chromium.org wrote: jam: It's a good idea; we came to the same conclusion. Good to hear :) I implemented the about:ipc UI as part of our performance focus last week. However, when I hooked it up, I noticed the logging itself was never fully ported from Windows; it uses a cross-process waitable event, but waitable_event_posix.cc isn't cross-process. So I'm working on that too. It might be easier to make this code work without events, i.e. by sending an IPC message to all child processes when logging state changes. agl has spent a bit of time looking into this and came to the conclusion that it's too much work (it's the reason that showModalDialog doesn't work on mac/linux btw). If you can make it work with the same behavior as the Windows event though, that'd be good since it'll make showModalDialog work. jrg On Mon, Aug 31, 2009 at 9:57 AM, John Abd-El-Malek j...@chromium.orgwrote: On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess sh...@chromium.org wrote: On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@chromium.org wrote: 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. It might be interesting to have the IO thread tag messages with the time as they go by, and have the UI thread keep track of the distribution of times that messages spend enqueued. Then we can set goals around how fast IPCs get pulled off the queue. The IPC logging code already keeps track of message dispatch time (i.e. from when Send() was called until the message handler started executing) and processing time (i.e. how long the handler took). I don't know how much of the UI is implemented on Mac, but on Windows this was only a few hours to implement, and it'll give a lot of insight on which messages are backed up/taking a lot of time. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
