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
Currently containers can only take tuples, and they set the named to layer_1, layer_2.... #44 was an initial prototype for this. But we need to do it for all container layers implemented in Lux.
The text was updated successfully, but these errors were encountered:
It would be nice if one could solve this issue to get type stable containers.
What was missing in that PR besides applybranching and applypairwisefusion? Maybe I will have some spare time to give it a try the next few days.
I tried to recreate the MWE I played with some weeks ago. I don't see the performance drop any longer (~20 additional allocations + exec time). Most likely, I actually benchmarked the construction of the chain. That would explain the additional allocations because I see a Body::Any for the construction with the current version vs no red line and 0 allocations with a NamedTuple.
Sorry for the false alarm. Finishing that PR to get rid of the red lines one sees using @code_warntype would be a good idea, though.
Currently containers can only take tuples, and they set the named to
layer_1, layer_2...
. #44 was an initial prototype for this. But we need to do it for all container layers implemented in Lux.The text was updated successfully, but these errors were encountered: