With pre-reading optimization (r50386) chrome startup time is under 1000ms on decent machines (down from 3000+ ms).
Problem: Chrome startup is not bad as a browser but quite slow for chrome frame as a plugin. A big factor in the slowdown is lots and lots of hard page faults during launch. A hard page fault causes disk read as opposed to a 'soft' page fault that simply uses/validates an existing page.
Solution:
Pre-read entire chrome.dll before calling LoadLibrary on Windows Vista onwards.
Errr, what?
Really, buffered read of chrome.dll as a data file in large (1MB) chunks using FILE_FLAG_SEQUENTIAL_SCAN speeds things up spectacularly by bringing in whole of chrome.dll in cache at once. This is much faster than individual page faults.
Normally during chrome startup, when chrome.dll is loaded and its entry point is called it continuously incurs hard page faults as seen in attached normal.png. For every page fault the following takes place:
- chrome.exe goes to zzzz.
- memory manager issues page aligned read request for max 32K, or 8 pages (less if next few pages are already in memory).
- the disk will take its own sweet time reading, likely will have to seek first.
- execution resumes and soon another fault happens inside chrome.dll at a random address...
Contrast this to the pre-read scenario:
Allocate 1 MB buffer, continuously read into the same buffer.
- chrome.exe goes to zzzz as before.
- data read requests are issued internally in 64K chunks.
- hints about sequential read speeds up overall reading.
- No page faults in chrome.dll after that!
Please refer to pre_read.png to see how it looks. Note the proportionate timing difference between the two scenarios. The numbers themselves are less indicative as this test was performed on a VM.
This code has been checked in for headless mode and the results are:
Page Cycler Test Results: look for a big drop in startup.
Increase in the IO bytes by ~ 16M on memory test as expected:
Why Vista onwards?
Windows Vista is more aggressive about using available memory for caching. It keeps the chrome.dll pages longer in cache. Vista onwards has superfetch that employs heuristics to monitor startup and speed up things by prefetching/keeping frequently used code/data in memory.
In Windows XP the pre-reading does not work at all since the file cache is quickly discarded and two separate copies are maintained for data vs image cache.
What's the downside?
Pre-reading approach brings in more pages than really necessary. Ideally, chrome.dll should be laid out such that there are different code sections for browser, renderer and so on. Then only those sections need to be warmed up for a particular type of launch. If it's not a lot of pages then we won't need pre-reading at all. Efforts for ordering code used at startup are already underway and should eventually lead us there.
The worst case behavior is on a system very low in available memory, reading in about 16 MB of data only to be discarded and faulted in subsequently. I suspect that things will be pretty bad already.
--
Chromium Developers mailing list: chromium-dev <at> chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
RSS Feed