System install setup detection wastes 0.8 seconds or more |
|||
Issue descriptionWhile investigating a possible setup slowdown ( crbug.com/609144 ) I noticed that setup.exe launches four times. The first invocation (launched by the browser process) tries to do the update/rename dance but fails because I have a system level Chrome install. The setup system then launches setup.exe again, this time launched by GoogleUpdate.exe, so that it will have the privileges needed to do the renames. This launch-and-relaunch dance seems to cost 0.84 s on my Z840 machine with lots of RAM and a boot SSD. This was measured from the time the first setup.exe was launched by the browser to the time the second setup.exe was launched by GoogleUpdate.exe. The actual cost may be more like 0.4 s - the lifetime of the first setup.exe process pair. This isn't a life-changing cost but if we can easily avoid spawning the processes unnecessarily then it would make Chrome updates slightly snappier. The entire upgrade process took 3.83 s, most of which is shutting down the old browser process.
,
Jul 7 2016
grt@: I remember you and Bruce having a discussion around this when he was in town. Was the decision that something could be done here?
,
Jul 7 2016
Some time could be saved by detecting in some better way that a system-level install is being upgraded so that setup.exe can be launched correctly the first time. I suspect that my claims of 0.8 s or 0.4 s are exaggerated - a subsequent trace showed less waste. But it feels like something could be done better.
,
Jul 14 2016
Yes, it's a simple thing to have it try the Google Update strategy first for system-level installs and fallback to the direct launch if it fails.
,
Aug 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b35a90bd1b901860dbc8db106649f207c60690e2 commit b35a90bd1b901860dbc8db106649f207c60690e2 Author: grt <grt@chromium.org> Date: Tue Aug 30 05:34:21 2016 Attempt the elevated path for the rename dance first for per-machine installs. This will eliminate some wasted cycles during the rename dance for the majority of installs, thereby leading to a better update experience for users. Also included in this change: removed some duplicated code and fixed up use of the registry. More on the latter: all integration points between Chrome and Google Update unconditionally take place in the 32-bit view of the Windows registry. As such, we use KEY_WOW64_32KEY everywhere even when it isn't strictly needed. It seems that this spot was missed during the great 64-bit-ification of Chrome. It just so happens that it's harmless for per-user installs since HKCU\Software is not redirected for 64-bit apps in the way that HKLM\Software is. BUG= 610305 R=brucedawson@chromium.org Review-Url: https://codereview.chromium.org/2283363005 Cr-Commit-Position: refs/heads/master@{#415163} [modify] https://crrev.com/b35a90bd1b901860dbc8db106649f207c60690e2/chrome/browser/first_run/upgrade_util_win.cc
,
Sep 2 2016
Fixed first appears in 55.0.2845.0. |
|||
►
Sign in to add a comment |
|||
Comment 1 by grt@chromium.org
, May 12 2016