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

Evaluating an AST node costs too much MEM? #6584

Open
effectfully opened this issue Oct 18, 2024 · 6 comments
Open

Evaluating an AST node costs too much MEM? #6584

effectfully opened this issue Oct 18, 2024 · 6 comments
Labels
Costing Anything relating to costs, fees, gas, etc. Low priority Doesn't require immediate attention status: triaged

Comments

@effectfully
Copy link
Contributor

@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 effectfully added Low priority Doesn't require immediate attention Costing Anything relating to costs, fees, gas, etc. status: triaged labels Oct 18, 2024
@nau
Copy link
Contributor

nau commented Oct 18, 2024

Attaching the statistics
stats.csv
image

@michele-nuzzi
Copy link

michele-nuzzi commented Oct 20, 2024

@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
        )
      )
    )
  )
)

@effectfully
Copy link
Contributor Author

will the let node 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 constr are 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.

@michele-nuzzi
Copy link

the cost of nodes evaluation will be the same right?

the number of lambdas is the same of the number of let

@michele-nuzzi
Copy link

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?

@effectfully
Copy link
Contributor Author

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 case and constr, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Costing Anything relating to costs, fees, gas, etc. Low priority Doesn't require immediate attention status: triaged
Projects
None yet
Development

No branches or pull requests

3 participants