[SERVER-51285] Optimize CancelationToken-usage in TaskExecutor to avoid extra call to schedule Created: 01/Oct/20  Updated: 10/Apr/22  Resolved: 12/Jan/21

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Matthew Saltz (Inactive) Assignee: Matthew Saltz (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-14060 Investigate changes in SERVER-51285: ... Closed
Related
related to SERVER-53734 Complete TODO listed in SERVER-51285 Backlog
related to SERVER-65413 Remove TODO listed for SERVER-51285 Closed
Sprint: Service Arch 2021-01-25
Participants:
Story Points: 4

 Description   

The first implementation of SERVER-50658 leads to running callbacks on network responses being less efficient, since there are two calls to schedule the callback in the thread pool rather than one. (Once to trigger the output future, and another to run the callback.) This ticket is to optimize it to be as efficient as it was before.

SERVER-52916 also has the same issue compared to scheduleWorkAt. This ticket is to optimize all ExecutorFuture-returning functions in TaskExecutor.



 Comments   
Comment by Matthew Saltz (Inactive) [ 12/Jan/21 ]

After offline discussion, we've decided to close this ticket as "Won't fix" since it's getting too complicated. If this becomes a performance problem in the future we can fix it properly, perhaps inside futures or individual executor implementations, but not enough code currently uses this for it to cause a regression in and of itself.

Generated at Thu Feb 08 05:25:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.