Improve New Tab Page load performance

Improve New Tab Page load performance.

This change nets another 65ms (20%) improvement in the duration between the
renderer requesting the NTP and it having all of the resources for the NTP
available and being completely done with layout on my Mac laptop in release
mode.

Move the handling of important resource requests needed for NTP layout from the
UI thread onto the IO thread.  This is handled by caching the necessary data on
the UI thread when possible, so that no profile or theme access is needed to
service the request.  There is often a lot of contention for the UI thread when
a new tab is created, and allowing these requests to be handled more directly
by the IO thread allows the renderer to lay the page out while the browser is
still busy doing UI work.

http://groups.google.com/group/chromium-dev/browse_thread/thread/7148074f807dc5f7

TEST=Do the new tab page and new incognito tab page still work?
     Are they faster?
BUG=13337
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=25232

[Mark Mentovai, 2009-09-01 18:59:48]

Brett, I think you were involved with a lot of this stuff initially.

Miranda, I see you have been working in here recently.

[Miranda Callahan, 2009-09-01 19:52:38]

Wow, this is great!  LGTM with nitlet, but wait for brettw, as he has much more
experience with this kind of improvement than I do.

http://codereview.chromium.org/179069/diff/1/4
File chrome/browser/dom_ui/chrome_url_data_manager.h (right):

http://codereview.chromium.org/179069/diff/1/4#newcode65
Line 65: // this should return NULL.  The default implementatin always returns
nit: implementation

[Mark Mentovai, 2009-09-01 22:55:03]

I'm positive there's something wrong with my laptp's "o" key.

[Mark Mentovai, 2009-09-02 03:17:09]

Brett, want to have a look?

[brettw, 2009-09-02 17:10:58]

http://codereview.chromium.org/179069/diff/1005/2009
File chrome/browser/browser_process_impl.h (right):

http://codereview.chromium.org/179069/diff/1005/2009#newcode56
Line 56: // It's safe to get the IO thread from its owner (the UI thread) or
from
Where is this necessary? BrowserProcess should really only be used from the UI
thread.

[brettw, 2009-09-02 18:30:12]

> ChromeURLDataManager::DataSource::SendResponse uses it to post
> DataAvailable onto the IO thread.  My change allows SendResponse to
> run directly from the IO thread.

In this case, we should use ChromeThread's names (see browser/chrome_thread.h)
for how. Took me a while to find this!

[Mark Mentovai, 2009-09-02 18:52:59]

brettw@chromium.org wrote:
> http://codereview.chromium.org/179069/diff/1005/2009#newcode56
> Line 56: // It's safe to get the IO thread from its owner (the UI
> thread) or from
> Where is this necessary? BrowserProcess should really only be used from
> the UI thread.

ChromeURLDataManager::DataSource::SendResponse uses it to post
DataAvailable onto the IO thread.  My change allows SendResponse to
run directly from the IO thread.

Mark

[Mark Mentovai, 2009-09-02 19:49:36]

Thanks, that was kind of obscure.  New version up.

http://codereview.chromium.org/179069/diff/8001/8006
File chrome/browser/dom_ui/chrome_url_data_manager.cc (right):

http://codereview.chromium.org/179069/diff/8001/8006#newcode275
Line 275: ChromeThread::GetMessageLoop(ChromeThread::IO)->PostTask(FROM_HERE,
Here.

[brettw, 2009-09-02 20:28:28]

LGTM