Cancel coming updates when certain JumpList APIs time out to fail
This CL records the timeout info when JumpListUpdater:: BeginUpdate or
JumpListUpdater::AddCustomCategory fails. This information is used to
decide if the next few updates are skipped. Previously, the jumplist
update run is aborted right away when any of the two steps above fails
without any runtime checked. It is possible that upon the failure,
those steps have already been running for quite a long time, making
them qualified to be considered as "timeout". In this case, we should
reduce the update frequency via skipping the next few updates so that
the slow machines have less burden.
[Determine the new threshold]
We drop the timeout threshold for JumpListUpdater::AddCustomCategory
to 320 ms from 500 ms. This is because before this change we monitor
the total execution time of AddCustomCategory for both most-visited
and recently-closed categories, while now we only monitor it for the
most-visited category. For most of the time, most-visited category has
5 items and recently-closed category has 3 items to process. In this
case, we have logged the ratio of the duration spent adding the two
categories using WinJumplist.RatioAddCategoryTime. It has a Gaussian
distribution with a peak value of 1.7 and a little more samples on the
right side of peak value. To make the new threshold not affect the
total number of timeout updates when 500 ms was used as the threshold,
the new threshold needs to separate the samples into 2 groups of a
same size. From the histogram, we can see that the ratio of 1.8 does
this job. Therefore, the new threshold for adding the most-visited
category alone should be around 500/2.8*1.8 = 320 ms.
BUG=40407, 736530
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
Review-Url: https://codereview.chromium.org/2965773002
Cr-Commit-Position: refs/heads/master@{#488899}
1 file changed
