You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you have a sealed trait with lots of subtypes (~1000 in my case, but the issue happens with much less), Magnolia runs into max-inlines issues or even triggers a compiler stack overflow.
This comes from the fact that the subtypesFromMirrormethod is not tail-recursive. It folds over the list of subtypes and increases the number of nested inline function calls and the stack depth proportionally to the number of subtypes.
On top of that, subtypesFromMirror calls .distinctBy(_.typeInfo).sortBy(_.typeInfo.full)on every iteration, which is very inefficient with large list of subtypes. This should be moved at the end of the loop.
The text was updated successfully, but these errors were encountered:
Indeed :) Would you be able maybe to work on a fix?
Not right now, I'm in the middle of a large Scala 3 migration and I ended up not using Magnolia since I could do it more simply. But I thought I'd share my findings anyway, hopefully it's relatively simple!
If you have a sealed trait with lots of subtypes (~1000 in my case, but the issue happens with much less), Magnolia runs into
max-inlines
issues or even triggers a compiler stack overflow.This comes from the fact that the
subtypesFromMirror
method is not tail-recursive. It folds over the list of subtypes and increases the number of nested inline function calls and the stack depth proportionally to the number of subtypes.See this example in Caliban on how it can be made tail-recursive.
On top of that,
subtypesFromMirror
calls.distinctBy(_.typeInfo).sortBy(_.typeInfo.full)
on every iteration, which is very inefficient with large list of subtypes. This should be moved at the end of the loop.The text was updated successfully, but these errors were encountered: