Move Isolated EL operations to EL protocol #3070
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Motivation
Right now the isolated view on the EventLoop has to implement
its interface in terms of UnsafeTransfer, because there are no
non-Sendable operations it can use.
That hurts us because we have to allocate an extra closure for all
these operations, making them slower than they need to be. This
is unavoidable in some contexts, but most EventLoops would be able
to offer a fast-path that avoids this extra allocation.
To achieve that, we need to move this logic into a customisation
point on the EventLoop protocol. Our fallback default implementation
can be the same as we do today.
Modifications
- Add customisation points for EventLoop for each of its operations
that has a protocol witness already.
- Add default implementations of these, using the implementation
from EventLoop.Isolated.
Results
No behavioural changes, but the code has moved.
glbrntt
reviewed
Jan 20, 2025
| let promise: EventLoopPromise<T> = self._wrapped.makePromise(file: file, line: line) | ||
| let scheduled = self.scheduleTask(deadline: deadline, task) | ||
|
|
||
| scheduled.futureResult.flatMap { $0 }.cascade(to: promise) |
There was a problem hiding this comment.
Can we save an alloc here if we use scheduled.futureResult.whenComplete { ... }?
There was a problem hiding this comment.
I don't think so: the flatMap unwraps an extra level of futureness.
There was a problem hiding this comment.
I mean like this (I appreciate it's more code than the flatMap + cascade):
scheduled.futureResult.whenComplete { result in
switch result {
case .success(let futureResult):
promise.completeWith(futureResult)
case .failure(let error):
promise.fail(error)
}
}There was a problem hiding this comment.
Yes, you're probably right. However, all the flatScheduleTask implementations in swift-nio follow this spelling. I've filed #3071 to track making the improvement generically, and so for now would rather keep this in line with the others.
There was a problem hiding this comment.
Thanks for filing that, makes sense to track them together.
glbrntt
approved these changes
Jan 20, 2025
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Right now the isolated view on the EventLoop has to implement its interface in terms of UnsafeTransfer, because there are no non-Sendable operations it can use.
That hurts us because we have to allocate an extra closure for all these operations, making them slower than they need to be. This is unavoidable in some contexts, but most EventLoops would be able to offer a fast-path that avoids this extra allocation.
To achieve that, we need to move this logic into a customisation point on the EventLoop protocol. Our fallback default implementation can be the same as we do today.
Modifications
Results
No behavioural changes, but the code has moved.