-
Notifications
You must be signed in to change notification settings - Fork 116
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
Wish list: Support inlined dispatch/combine calls #238
Comments
I might need a bit longer to work out the implications of this... have you any idea what the runtime performance improvement might be? Obviously it would depend on what typeclass we're deriving, but a side-by-side comparison of a hand-rolled version of the derivation we could expect from this inlining against Magnoia's current derivation would be interesting... |
The point is to generate the exact same code for an instance as you would write if you hand-rolled it. Because you can output arbitrary trees in these functions you can optimize as much as you please - the difference is that you get some tricky reflection work pre-done and packed nicely into data types by Magnolia. |
Should be careful with inlining because you don't want to produce too big trees 😄 |
Can this wait until Scala 3? |
Seems like it might happen automatically in 3 as long as user methods are |
Theoretically it may be possible to generalize
CaseClass/SealedTrait
structures to put trees in there instead of runtime values and parameterize the Magnolia macro with dispatch/combine before creating the macro, e.g.This would allow to remove all the runtime cost for the creation of CaseClass/SealedTrait structures & inline all the information directly into the generated codecs
The text was updated successfully, but these errors were encountered: