Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.0.0
-
None
Description
Future<> is more expensive to construct than necessary. A few optimizations could be pursued:
- Store the future's result in the same allocation which houses the ConcreteFutureImpl
- Apply the small buffer optimization to FnOnce so that small continuations do not incur another heap allocation
- Contention for the global waiter lock is unlikely to be an issue, but it'd be good to measure
- Futures will usually have few callbacks, so a vector may be unnecessary