Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-95571

Reduce overhead of non-future returning ExecutorFuture continuations

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Server Programmability

      A continuation chained to an ExecutorFuture will be scheduled on the underlying executor when it is ready to run, even if the prior continuation was already running on the executor. This can reduce performance if the executor is busy and there are a lot of continuations to chain (as seen in SERVER-93489). It would be a nice performance improvement if trivial continuations that don't perform any async work (i.e. don't return futures, or happen to have returned a ready future) don't need to call OutOfLineExecutor::schedule.

      As an example, the following currently results in three calls to schedule, when it could reasonably be done in one, since at each step, the value needing to be passed into the next continuation is immediately available.

      ExecutorFuture(exec).then([]() { return 5; })
                          .then([](int x) { return x + 1; })
                          .then([](int y) { return y + 1; })
                          .get();
      

      Some notes from mathias@mongodb.com on what an implementation of this might look like:

      The hard part is that we need the core future "glue" logic to be ExecutorFuture aware. This is (mostly) trivial with coroutines, but a bit tricky with how we currently do FutureImpl. What should happen is after completing a callback it should check if the next callback to run is on the same executor, and if so, just call it directly after popping the prior callback's frame off the stack. However, that requires that we have a core trampoline that handles invoking each callback in a chain-walking loop rather than what we do right now where each callback is responsible for calling the next recursively.

            Assignee:
            Unassigned Unassigned
            Reporter:
            patrick.freed@mongodb.com Patrick Freed
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: