My recommended strategy would be to tune the delay based on whether the user has recently used the jumplist. That is, if the user has selected one of the jumplist entries in, say, the last week or month or whatever then the delay should probably be zero, on the assumption that it needs to be short enough so that if they close a tab and then immediately regret it they will find it. For these users any longer delay is pointless because if it is long enough that they might be able to close another tab (and therefore coalesce the operations) then it is also long enough that they could open up the jumplist. Therefore, logically, it needs to be zero.

For users who have not recently used the jumplist we could leave the delay at 3.5 s (or some other arbitrary number) or we could decide that it is now efficient enough that these shenanigans are no longer needed and also have no delay.

For the second case it might make sense to scale the delay based on machine speed, as suggested in the initial comment.

Just my two cents.

Re comment #1: Unfortunately, I don't think it's possible for an user to query the recent usage of the JumpList per the current implementation. I am logging the time interval of update notifications to see if there is anything I can do based on that. 

An interesting fact from UMA is that the most-visited category is used about 5x more than the recently-closed category. Since the delay is not very annoying for the most-visited category, I think the option of the delay time may be more flexible based on the fact.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/feded507d0e942303f1ac97140059411c0401e43

commit feded507d0e942303f1ac97140059411c0401e43
Author: chengx <chengx@chromium.org>
Date: Wed Jul 05 20:31:31 2017

Log the time interval between adjacent JumpList update notifications

This CL logs the time interval between adjacent update notifications
that fall into the 3500 ms interval. This helps to develop a better
delay strategy.

BUG= 733034 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng

Review-Url: https://codereview.chromium.org/2966123002
Cr-Commit-Position: refs/heads/master@{#484341}

[modify] https://crrev.com/feded507d0e942303f1ac97140059411c0401e43/chrome/browser/win/jumplist.cc
[modify] https://crrev.com/feded507d0e942303f1ac97140059411c0401e43/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/93fc3e41c9acda3fe3b2abca635f995f18889d8f

commit 93fc3e41c9acda3fe3b2abca635f995f18889d8f
Author: chengx <chengx@chromium.org>
Date: Thu Jul 06 02:46:26 2017

Remove delay for the first JumpList top site sync in one session

In current JumpList implementation, when the first tab is closed in
one session, it doesn't trigger an update but a TopSites sync. This
sync will then trigger an update for both mostly visited and recently
closed categories. We don't need to delay this TopSites sync,
otherwise it will take at least 7 seconds to get the JumpList
refreshed after the first tab is closed in one session.

BUG= 733034 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng

Review-Url: https://codereview.chromium.org/2965973002
Cr-Commit-Position: refs/heads/master@{#484446}

[modify] https://crrev.com/93fc3e41c9acda3fe3b2abca635f995f18889d8f/chrome/browser/win/jumplist.cc
[modify] https://crrev.com/93fc3e41c9acda3fe3b2abca635f995f18889d8f/chrome/browser/win/jumplist.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1fca937e8656e8b5c5842bf7e99eecfe89b18cad

commit 1fca937e8656e8b5c5842bf7e99eecfe89b18cad
Author: chengx <chengx@chromium.org>
Date: Thu Jul 06 03:13:17 2017

Log the ratio of the duration spent adding the two JumpList categories

This CL logs the ratio of the duration spent adding the most-visited
category compared to the duration spent adding the recently-closed
category. In crrev/2965773002, a new timeout threshold is needed after
updating the usage of JumpListUpdater::AddCustomCategory. See more
details in the last paragraph of the CL description. This CL logs the
ratio to help generate a good threshold.

BUG= 733034 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng

Review-Url: https://codereview.chromium.org/2964873002
Cr-Commit-Position: refs/heads/master@{#484452}

[modify] https://crrev.com/1fca937e8656e8b5c5842bf7e99eecfe89b18cad/chrome/browser/win/jumplist.cc
[modify] https://crrev.com/1fca937e8656e8b5c5842bf7e99eecfe89b18cad/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/30f7b97ee69160736dc3a1087bae880264dafd24

commit 30f7b97ee69160736dc3a1087bae880264dafd24
Author: Xi Cheng <chengx@chromium.org>
Date: Tue Jul 11 18:57:42 2017

Update NotificationTimeInterval, retire AddTasksDuration for JumpList

The metric WinJumplistUpdater.AddTasksDuration is no longer needed.
WinJumplist.NotificationTimeInterval is updated to track the percentage
of the notifications that get coalesced.

Bug:  733034 , 738126 
Change-Id: I92669e5cd261a47df8a3a782ea64072c106a4195
Reviewed-on: https://chromium-review.googlesource.com/565580
Commit-Queue: Xi Cheng <chengx@chromium.org>
Reviewed-by: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485687}
[modify] https://crrev.com/30f7b97ee69160736dc3a1087bae880264dafd24/chrome/browser/win/jumplist.cc
[modify] https://crrev.com/30f7b97ee69160736dc3a1087bae880264dafd24/chrome/browser/win/jumplist_updater.cc
[modify] https://crrev.com/30f7b97ee69160736dc3a1087bae880264dafd24/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2d9bd76321496667b2b4edf6445f72cef3780fad

commit 2d9bd76321496667b2b4edf6445f72cef3780fad
Author: Xi Cheng <chengx@chromium.org>
Date: Fri Jul 28 03:32:14 2017

Delay JumpList updates less in general, and much less for JumpList users

This CL reduces the JumpList update delay from 3500 ms to 2000 ms in
general, as 3500 ms is noticeably long. For users have used JumpList to
open up webpages in one session, the delay is further reduced to 500 ms
for the remaining session. A delay of 500 ms can still prevent unnecessary
updates when tabs are closed rapidly via Ctrl-W.

Bug:  733034 
Cq-Include-Trybots: master.tryserver.chromium.win:win10_chromium_x64_rel_ng
Change-Id: Ia605ebb1677c1c12de74e37df33d81b2813eaf36
Reviewed-on: https://chromium-review.googlesource.com/585029
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Xi Cheng <chengx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490240}
[modify] https://crrev.com/2d9bd76321496667b2b4edf6445f72cef3780fad/chrome/browser/ui/startup/startup_browser_creator.cc
[modify] https://crrev.com/2d9bd76321496667b2b4edf6445f72cef3780fad/chrome/browser/win/jumplist.cc

Now the delay is 500 ms for JumpList users, and 2000 ms elsewhere.

@chengx-- Could you please provide us the manual repro steps , if it requires the manual verification from TE End.

Thanks!

@hdodda-- As long as the CL as in comment #9 doesn't cause any crashes, I think we are good here. I have tested it in latest Canary and it's working as expected. So I don't think it requires the verification from TE end.

Let me know if you have any questions. Thanks!