Trace is here
https://drive.google.com/a/google.com/folderview?id=0BwopmxS_1cwWRWVXbmdITHpsVkE&usp=sharing

The update period seems to run from 5.1 s into the trace (the click that presumably initiates the update) to 18.6 s into the trace (when the new browser process takes focus).

For the five seconds from ~8.6 to 13.85 s into the trace the disk is basically 100% busy. During those five seconds chrome.exe (6912) (the old browser process) does 43 file buffer flushes, which certainly exacerbates the disk-busy situation. The trace suggests that the disk service cost of the 43 flushes is approximately 2 seconds, although I don't know how accurate that estimate is. Unfortunately it's not clear where those disk flushes are coming from. There are 129 flushes over the the entire upgrade time period - the 5 second period was only examined more closely because there it was clear that the file I/O thread was blocking shutdown.

In UIforETW if you put "DiskReadInit+DiskWriteInit+DiskFlushInit" in the Settings dialog, "Extra kernel stackwalks" field then it will record stack walks on disk reads, writes, and flushes, which may give useful information for next time.

Some flushes are presumably necessary in order to maintain database integrity, but 129 flushes during shutdown seems excessive. If the flushes were removed or minimized then the writes could either be postponed or better scheduled - perhaps.

The profiled machine is slowed down by anti-virus and malware detection software, and by tracing sharing the disk with other I/O (why is there only one disk and no SSD?), but on the other hand the 64 GB of RAM allows significant caching which gives an advantage.

So, additional traces would be appreciated.

My Z840 needed a Chrome update so I recorded a trace with DiskReadInit+DiskWriteInit+DiskFlushInit enabled. This means that I got call stacks on all of the flushes (and the reads and writes).

The total upgrade time for me, from clicking the last button to the new Chrome browser process gaining focus, was just 3.8 s (from 9.24 s to 13.08 s in my trace). 3.16 s of that time was shutdown - the old browser process didn't shut down until ~12.4 s into the trace. This is faster than in manzagop@'s trace because I am using a Z840 (SSD boot drive) but still long enough to show that shutting down and installing the upgrade is the limiting factor.

We should either try to improve the performance of browser-process shutdown, or we should display some UI so that users know what is going on - 3.8 s is a long time to leave the user waiting, and we leave most users waiting for far longer.

I had ~22 tabs open.

The trace shows setup.exe being launched four times, in pairs. The first time by the old browser process, and the third time by GoogleUpdate.exe. The second and fourth instances were launched by the first and third. The last setup.exe/GoogleUpdate.exe/GoogleUpdateOnDemand.exe process disappeared at 12.s s into the trace.

During shutdown the browser process flushed file buffers 114 times. Because I have an SSD this only took 0.67 s, but on a spinning disk this can be a painful process. The browser process also read 9 MB from the disk and wrote 4 MB - those would be greater on machines with less disk cache, but the flushes are the main concern.

110 of the flushes come through chrome.dll!winSync. The inverted call stack below shows where the calls are coming from. It's a bit hard to follow, but pageSyncHotJournal was the immediate caller for 76 of these, called indirectly by sql::Connection::Close, which was called by 13 different callers, with the DOMStorageDatabase destructor accounting for 49 of those. sqlite30sSync accounted for another 34 calls, and it was called by three different functions.

Do we really have 76 different database connections open? All of which require disk syncs on closing? Rly?

Count	IO Init Stack - (Callers of chrome.dll!winSync)
110	chrome.dll!winSync
76	|- chrome.dll!pagerSyncHotJournal
76	|  chrome.dll!sqlite3PagerClose
76	|  chrome.dll!sqlite3BtreeClose
76	|  chrome.dll!sqlite3LeaveMutexAndCloseZombie
76	|  chrome.dll!sqlite3Close
76	|  chrome.dll!_sqlite3_close
76	|  chrome.dll!sql::Connection::CloseInternal
76	|  chrome.dll!sql::Connection::Close
49	|  |- chrome.dll!content::DOMStorageDatabase::~DOMStorageDatabase
14	|  |- chrome.dll!content::DOMStorageDatabase::Close
1	|  |- chrome.dll!extensions::ActivityDatabase::Close
3	|  |- chrome.dll!net::SQLitePersistentCookieStore::Backend::InternalBackgroundClose
1	|  |- chrome.dll!WebDatabaseBackend::ShutdownDatabase
1	|  |- chrome.dll!base::internal::Invoker<>::Run
1	|  |- chrome.dll!content::AppCacheDatabase::~AppCacheDatabase
1	|  |- chrome.dll!content::WebRTCIdentityStoreBackend::SqlLiteStorage::Close
1	|  |- chrome.dll!history::TopSitesDatabase::~TopSitesDatabase
1	|  |- chrome.dll!base::RefCountedThreadSafe<IconLoader,base::DefaultRefCountedThreadSafeTraits<IconLoader> >::Release
1	|  |- chrome.dll!syncer::syncable::DirectoryBackingStore::~DirectoryBackingStore
1	|  |- chrome.dll!net::SQLiteChannelIDStore::Backend::InternalBackgroundClose
1	|  |- chrome.dll!storage::QuotaDatabase::~QuotaDatabase
34	|- chrome.dll!sqlite3OsSync
18	|  |- chrome.dll!syncJournal
8	|  |- chrome.dll!sqlite3PagerSync
8	|  |- chrome.dll!pager_end_transaction

Trace is available and is "2016-05-06_13-42-47 chrome upgrade.etl"

Why is this R-V-G?

I'm not sure. No reason to keep it that way?

Archiving P3s older than 1 year with no owner or component.