Cancel the next 10 updates if there's a timeout in jumplist updater
Notifying OS about the jumplist update consists of 4 steps in order:
BeginUpdate, AddCustomCategory, AddTasks and CommitUpdate, all of
which shouldn't take long. However, UMA data shows that each step can
take up to tens of seconds for some users, especially for steps
Beginupdate, AddCustomCategory and CommitUpdate. Since they are mostly
Windows API calls, we can assume this is due to user machines (which
can be very slow) with a pretty high confidence, and also there's not
much we can improve on Chrome's side.
Previously, we cancel the current jumplist update if BeginUpdate takes
more than 500 ms, based on the assumption that the following steps
will also take a long time if BeginUpdate does. The UMA data shows
that this benefits some users but not the majority, which indicates
that the runtime of these steps is not highly correlated. That is,
AddCustomCategory and/or CommitUpdate can still take a long time even
if BeginUpdate finishes quickly. To alleviate this issue, we should
reduce the frequency of jumplist updates if any of those steps times
out. In more details, we cancel the next 10 updates if BeginUpdate or
AddCustomCategory takes more than 500 ms, or takes more than 500 ms,
or CommitUpdate takes more than 1000 ms, which are the cutoffs for
99.5% JumpList update samples in Canary for the three steps,
respectively. If the machine is always slow making every jumplist
update time out, this penalty of cancelling the next 10 updates can
alleviate this issue by 90%.
BUG=40407, 179576
Review-Url: https://codereview.chromium.org/2868303003
Cr-Commit-Position: refs/heads/master@{#471430}
2 files changed
