-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#1017 make marshaller composition more lazy #1019
Conversation
Test PASSed. |
val f2 = (_: ExecutionContext) ⇒ (a: A) ⇒ FastFuture.successful(f1(a) :: Nil) | ||
new Marshaller[A, B] { | ||
def apply(value: A)(implicit ec: ExecutionContext) = | ||
try f2(ec)(value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you inline those functions? The whole execution is strict so preallocation those lambdas is not beneficial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 plz :)
Good analysis, thanks. |
@raboof can you inline those lambdas and merge after validation? Would be nice to have in the next release? |
I'll merge and cleanup |
Resolves #1017 |
I have this nagging feeling this could be made more elegant by doing something other than making these anonymous `Marshaller` subclasses and overriding 'compose', but for now this'll do :).
I have this nagging feeling this could be made more elegant by doing something other than making these anonymous `Marshaller` subclasses and overriding 'compose', but for now this'll do :).
I have this nagging feeling this could be made more elegant by doing something other than making these anonymous `Marshaller` subclasses and overriding 'compose', but for now this'll do :).
When using
Marshalling.oneOf
, in some situations each marshaller is actually executed before picking the most suitable result.While indeed we can't avoid allocating a
Marshalling
for eachMarshaller
(that would need a wider overhaul as described in #243), the actual marshalling can still be lazy at that point (https://github.com/akka/akka-http/blob/master/akka-http/src/main/scala/akka/http/scaladsl/marshalling/Marshaller.scala#L168).It seems
Marshaller.compose
is forcing the early evaluation. This PR appears to confirm that, though it isn't obvious we can work that through without performing the ugly hacks in here.