IntersectMBO
Evaluating an AST node costs too much MEM?
@nau reported some stats and they suggest that evaluating AST nodes consumes 96.66% of MEM, which is an absurdly huge amount compared to the 3.34% that builtins consume. Does it really have to be that way? And if it does, should we prioritize working on solutions making MEM consumption lower by evaluating fewer AST nodes or producing fewer evaluation frames? For example by adding fix (issue) or let (issue) to the AST.
@effectfully will the let node allow for multiple variables?
eg
(let a b c d
body
)
instead of
(let a
(let b
(let c
(let d
body
)
)
)
)
Otherwise case and constr are only 2 nodes of difference
(case
(constr 0 a b c d)
(lam a
(lam b
(lam c
(lam d
body
)
)
)
)
)
will the
letnode allow for multiple variables?
I'm not sure if that'll buy us much (or even anything at all) in terms of size or performance. Or can you think of something?
Otherwise case and
constrare only 2 nodes of difference
The issue with constr is that you need those arguments to get fed into lambdas one by one and it's just less efficient to evaluate applied lambdas than it is to evaluate let nodes, especially in the current Haskell VM. Plus lets are more readable and I'd rather make UPLC readable if I can help it.
the cost of nodes evaluation will be the same right?
the number of lambdas is the same of the number of let
I'm not sure if that'll buy us much (or even anything at all) in terms of size or performance
Why this is not a problem for case and constr, which both have unbounded number of children?
the cost of nodes evaluation will be the same right?
the number of lambdas is the same of the number of let
You're asking an interesting question, I'll bring it up to the team.
Why this is not a problem for
caseandconstr, which both have unbounded number of children?
Those have to have them, it wouldn't make much sense to only allow constructors with a single argument. Single lets on the other hand are perfectly reasonable.