Skip to content
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

Merged
merged 1 commit into from
Apr 28, 2017

Conversation

raboof
Copy link
Member

@raboof raboof commented Apr 7, 2017

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 each Marshaller (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.

@akka-ci akka-ci added validating PR that is currently being validated by Jenkins tested PR that was successfully built and tested by Jenkins and removed validating PR that is currently being validated by Jenkins labels Apr 7, 2017
@akka-ci
Copy link

akka-ci commented Apr 7, 2017

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)
Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 plz :)

@ktoso
Copy link
Member

ktoso commented Apr 18, 2017

While indeed we can't avoid allocating a Marshalling for each Marshaller (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).

Good analysis, thanks.

@jrudolph
Copy link
Member

@raboof can you inline those lambdas and merge after validation? Would be nice to have in the next release?

@ktoso
Copy link
Member

ktoso commented Apr 28, 2017

I'll merge and cleanup

@ktoso ktoso merged commit 288be40 into master Apr 28, 2017
@ktoso ktoso deleted the lazier-marshaller-composition branch April 28, 2017 03:41
@ktoso ktoso changed the title [WIP] #1017 make marshaller composition more lazy #1017 make marshaller composition more lazy Apr 28, 2017
@ktoso
Copy link
Member

ktoso commented Apr 28, 2017

Resolves #1017

raboof added a commit that referenced this pull request Apr 28, 2017
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 :).
ktoso pushed a commit that referenced this pull request Apr 28, 2017
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 :).
tomrf1 pushed a commit to tomrf1/akka-http that referenced this pull request Aug 13, 2017
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 :).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tested PR that was successfully built and tested by Jenkins
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants