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.
Currently,
Endpoint
s are backed byOption[(Input, Rerrunable[Output[A]])]
s. There is nothing wrong with that type and it provides a great insight on what happens in the endpoint, but there is a way to make it 1) simpler and 2) faster.Let's flatten
Option[Tuple2[_, _]]
into a new typeEndpointResult
(ADT with two cases: matched vs. skipped) and save some allocations on option creations.In addition to that this PR cleans up a couple of places that I think were poorly structured:
Option
).awaitX
variants to visually signal the reader that the call is blocking. They also take optionalDuration
, which comes in handy in tests.UPDATE: I decided to give up on a mutable
EndpointResult
for now since it doesn't buy much of performance improvement but tradeoffs immutability. The most recent benchmark run is here (https://gist.github.com/vkostyukov/e54092f843280dc3f8930c1d359db342). TL;DREndpointResult[_]
performs better or same asOption[Tuple2[_, _]]
.