Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2965773002:
Cancel coming updates when certain JumpList APIs time out to fail (Closed)
|
Created:
3 years, 5 months ago by chengx Modified:
3 years, 5 months ago Reviewers:
grt (UTC plus 2) CC:
chromium-reviews Target Ref:
refs/heads/master Project:
chromium Visibility:
Public. |
DescriptionCancel 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}
Committed: https://chromium.googlesource.com/chromium/src/+/a43fcb472fc064f1870d33daa8c8defe905b33d0
Patch Set 1 #
Total comments: 2
Patch Set 2 : Explain why we only time the most visited category. #
Total comments: 4
Patch Set 3 : Update comments #Patch Set 4 : Adjust the threshold to 320 ms, explained in CL description #Patch Set 5 : Merge branch 'master' of https://chromium.googlesource.com/chromium/src into recordtimeoutinfoforfa… #Patch Set 6 : Fix build #Messages
Total messages: 52 (42 generated)
Description was changed from ========== record timeout info for failed jumplist updater steps BUG= ========== to ========== record timeout info for failed jumplist updater steps BUG= CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ==========
Description was changed from ========== record timeout info for failed jumplist updater steps BUG= CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ========== to ========== Record timeout info when JumpList BeginUpdate/AddCustomCategory fails This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two above steps fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most-visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ==========
Description was changed from ========== Record timeout info when JumpList BeginUpdate/AddCustomCategory fails This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two above steps fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most-visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ========== to ========== Record timeout info when JumpList BeginUpdate/AddCustomCategory fails This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two above steps fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ==========
Description was changed from ========== Record timeout info when JumpList BeginUpdate/AddCustomCategory fails This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two above steps fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ========== to ========== Record timeout info when JumpList BeginUpdate/AddCustomCategory fails This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ==========
Description was changed from ========== Record timeout info when JumpList BeginUpdate/AddCustomCategory fails This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ========== to ========== Record timeout info when JumpList BeginUpdate/AddCustomCategory fails This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ==========
The CQ bit was checked by chengx@chromium.org to run a CQ dry run
Patchset #1 (id:1) has been deleted
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Patchset #1 (id:20001) has been deleted
chengx@chromium.org changed reviewers: + grt@chromium.org
PTAL, thanks!
The CQ bit was checked by chengx@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2965773002/diff/40001/chrome/browser/win/jump... File chrome/browser/win/jumplist.cc (right): https://codereview.chromium.org/2965773002/diff/40001/chrome/browser/win/jump... chrome/browser/win/jumplist.cc:81: constexpr base::TimeDelta kTimeOutForAddCustomCategory = this is now specifically "timeout for add most visited pages custom category" since recently closed is no longer timed. please make this more explicit in the documentation here. why does it make sense to so accurately time the most visited category but not the recently closed category? it makes sense that the first category added may take longer than the second since the code and data may be "hot" for the second category. if that's the reason for only timing one of the two, then i think it's worth documenting that. otherwise, what's the advantage of timing only one rather than both?
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Patchset #2 (id:60001) has been deleted
Patchset #2 (id:80001) has been deleted
Please see my explanation below. Thanks! https://codereview.chromium.org/2965773002/diff/40001/chrome/browser/win/jump... File chrome/browser/win/jumplist.cc (right): https://codereview.chromium.org/2965773002/diff/40001/chrome/browser/win/jump... chrome/browser/win/jumplist.cc:81: constexpr base::TimeDelta kTimeOutForAddCustomCategory = On 2017/06/30 21:34:12, grt (UTC plus 2) wrote: > this is now specifically "timeout for add most visited pages custom category" > since recently closed is no longer timed. please make this more explicit in the > documentation here. I've updated the documentation. > why does it make sense to so accurately time the most visited category but not > the recently closed category? it makes sense that the first category added may > take longer than the second since the code and data may be "hot" for the second > category. if that's the reason for only timing one of the two, then i think it's > worth documenting that. otherwise, what's the advantage of timing only one > rather than both? Here is the reason. 1. If processing the first category times out or fails, there is no need to process the second category. In this case, we are not able to time both categories. Then we need to select one category. 2. The most visited category is selected because it always has 5 items, while the number of items in recently closed category varies from 1 to 3. This means the runtime of AddCustomCategory API should be fixed for most visited category, but not for recently closed category. So a fixed timeout threshold is actually only valid for most visited category. That's why it makes sense to only time the most visited category, but not the other one. I've added the explanation above to the file.
https://codereview.chromium.org/2965773002/diff/100001/chrome/browser/win/jum... File chrome/browser/win/jumplist.cc (right): https://codereview.chromium.org/2965773002/diff/100001/chrome/browser/win/jum... chrome/browser/win/jumplist.cc:761: // 1. If processing the first category times out or fails, there is no need to i understand why it makes sense to consider this a timeout if it fails after the elapsed time (as you've done for BeginUpdate above), but i'm less certain about the fine-tuning to ratchet down the timeout for only the first operation. i think there are reasons why the first op may take > 5/8 of the total time, while the second op may take < 3/8. how many users will be left without an accurate jumplist due to this aggressive level of back-off? how can you measure the benefit to the population "helped" by this in relation to the feature being flaky for those "hurt" by it? https://codereview.chromium.org/2965773002/diff/100001/chrome/browser/win/jum... chrome/browser/win/jumplist.cc:764: // 2. Most visited category is selected because it always has 5 items, while why doesn't a newish user have fewer than 5? to verify, i just launched 61.0.3147.0 canary with a new user data dir. with a little fiddling, i can't get the jumplist to show anything at all. why doesn't the following sequence result in a jumplist with one recently closed item: - chrome.exe --user-data-dir=c:\some\new\dir - open a new tab - navigate to nytimes.com - close that tab - wait a few seconds - open the jumplist
Description was changed from ========== Record timeout info when JumpList BeginUpdate/AddCustomCategory fails This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ========== to ========== Cancel coming updates when a few JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ==========
Description was changed from ========== Cancel coming updates when a few JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ========== to ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ==========
Patchset #3 (id:120001) has been deleted
PTAL, thanks! https://codereview.chromium.org/2965773002/diff/100001/chrome/browser/win/jum... File chrome/browser/win/jumplist.cc (right): https://codereview.chromium.org/2965773002/diff/100001/chrome/browser/win/jum... chrome/browser/win/jumplist.cc:761: // 1. If processing the first category times out or fails, there is no need to On 2017/07/03 06:24:15, No reviews Jul 3 - 19 wrote: > i understand why it makes sense to consider this a timeout if it fails after the > elapsed time (as you've done for BeginUpdate above), but i'm less certain about > the fine-tuning to ratchet down the timeout for only the first operation. i > think there are reasons why the first op may take > 5/8 of the total time, while > the second op may take < 3/8. how many users will be left without an accurate > jumplist due to this aggressive level of back-off? how can you measure the > benefit to the population "helped" by this in relation to the feature being > flaky for those "hurt" by it? To answer your question, I landed crrev/2964873002 to log the ratio of the duration spent adding the two categories ONLY when the most-visited category has 5 items and the recently-closed category has 3 items. The UMA histogram is called "WinJumplist.RatioAddCategoryTime". The ratio is multiplied by 10 to retain sub-decimal precision. The histogram has a Gaussian distribution with peak value of 17 (so the ratio is 1.7 as it's multiplied by 10). This aligns with the 5/3. I know this adjustment of this threshold is imperfect, but I think it's more accurate than measuring the total time spent on two categories. The most-visited category has 5 items for most of the time after the user closes 5-ish tabs during his entire using Chrome. In comparison, the recently-closed category has 3 items only after the user closes 3 tabs in one Chrome session. It has a much higher frequency of having less than 3 items. So measuring the most-visited category alone is more stable than measuring both of them. https://codereview.chromium.org/2965773002/diff/100001/chrome/browser/win/jum... chrome/browser/win/jumplist.cc:764: // 2. Most visited category is selected because it always has 5 items, while On 2017/07/03 06:24:15, No reviews Jul 3 - 19 wrote: > why doesn't a newish user have fewer than 5? It does have fewer than 5 items. Then it should take less time than the new threshold, therefore it won't time out. I have updated the comments to make it more accurate. > to verify, i just launched 61.0.3147.0 canary with a new user data dir. with a > little fiddling, i can't get the jumplist to show anything at all. why doesn't > the following sequence result in a jumplist with one recently closed item: > - chrome.exe --user-data-dir=c:\some\new\dir > - open a new tab > - navigate to http://nytimes.com > - close that tab > - wait a few seconds > - open the jumplist I tried a few times but could not repro though. One thing I noticed is that it took 7+ seconds to initialize the first update. This is due to that the tab restore notification from the tab closure has to wait for 3.5 s to get through. It then generates a TopSites sync, which updates both categories. The TopSites notification waits for another 3.5 s to get through. Therefore, it takes 7+ s to finish the first update. I've landed crrev/2965973002 to fix this.
Description was changed from ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Since typically most-visited category has 5 items to process and recently-closed category has 3 items to process, the new threshold should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ========== to ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, we have used WinJumplist.RatioAddCategoryTime to prove that the ratio of the duration spent adding the two categories is around 5/3 = 1.7. Therefore, the new threshold for adding the most-visited category alone should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ==========
Description was changed from ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 300 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, we have used WinJumplist.RatioAddCategoryTime to prove that the ratio of the duration spent adding the two categories is around 5/3 = 1.7. Therefore, the new threshold for adding the most-visited category alone should be around 500*5/8 = 312.5 ms. We choose 300 ms for simplicity. BUG=40407, 736530 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng ========== to ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 350 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ==========
Description was changed from ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 350 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ========== to ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when we used 500 ms threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ==========
Description was changed from ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when we used 500 ms threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ========== to ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when we used 500 ms threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ==========
Description was changed from ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when we used 500 ms threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ========== to ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when 500 ms was used as the threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ==========
Description was changed from ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when 500 ms was used as the threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ========== to ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when 500 ms was used as the threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ==========
Description was changed from ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when 500 ms was used as the threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ========== to ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. [Determine the new threshold] The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when 500 ms was used as the threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ==========
Description was changed from ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. [Determine the new threshold] The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when 500 ms was used as the threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ========== to ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. [Determine the new threshold] The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when 500 ms was used as the threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ==========
Description was changed from ========== Cancel coming updates when certain JumpList APIs time out to fail This CL records the timeout information when JumpListUpdater:: BeginUpdate or JumpListUpdater::AddCustomCategory fails. This information is then used to decide if the next few updates should be skipped. Previously, the jumplist update run is aborted right away when any of the two steps above fails without any runtime being 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 to alleviate the machine. [Determine the new threshold] The timeout threshold for JumpListUpdater::AddCustomCategory is reduced from 500 ms to 320 ms. This is because previously we monitor the total runtime of AddCustomCategory for both most-visited and recently-closed categories, while now we only monitor it for the most- visited category. Typically, most-visited category has 5 items to process and recently-closed category has 3 items to process. In this scenario, 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 distribution on the right side of peak value. In order to make the new threshold not affect the total number of timeout samples when 500 ms was used as the threshold for two categories, the new threshold needs to separate the samples into 2 groups of a same size. From the histogram, 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 ========== to ========== 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 ==========
lgtm
The CQ bit was checked by chengx@chromium.org
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by chengx@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: win10_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win10_chromium_x6...)
The CQ bit was checked by chengx@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by chengx@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from grt@chromium.org Link to the patchset: https://codereview.chromium.org/2965773002/#ps200001 (title: "Fix build")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 200001, "attempt_start_ts": 1500852402411360,
"parent_rev": "1796ec93fd927e373592aa7c74756f610a28422b", "commit_rev":
"a43fcb472fc064f1870d33daa8c8defe905b33d0"}
Message was sent while issue was closed.
Description was changed from ========== 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 ========== to ========== 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} Committed: https://chromium.googlesource.com/chromium/src/+/a43fcb472fc064f1870d33daa8c8... ==========
Message was sent while issue was closed.
Committed patchset #6 (id:200001) as https://chromium.googlesource.com/chromium/src/+/a43fcb472fc064f1870d33daa8c8... |
