-
Notifications
You must be signed in to change notification settings - Fork 88
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
Create a prepareTxScripts function for profiling scripts #721
Conversation
Transactions CostsSizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using
Script summary
Cost of Init Transaction
Cost of Commit TransactionCurrently only one UTxO per commit allowed (this is about to change soon)
Cost of CollectCom Transaction
Cost of Close Transaction
Cost of Contest Transaction
Cost of Abort TransactionSome variation because of random mixture of still initial and already committed outputs.
Cost of FanOut TransactionInvolves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Document any hydra-specific steps needed for this? where?
that would be great, I think the documentation would be a good place for that. In general, we should move all the technical stuff that's in the wiki in the docs for more exposure and better tracking, this includes coding conventions, build guidelines, releases strategy, etc.
How to ensure these functions stay exposed at the ledger/plutus-core?
Not sure what you mean here, we don't have much control over the plutus or ledger codebase so if they decide to drop support in some future version, the best we can do is try to be warned in advance and yell.
Add another hydra-specific function to identify scripts by matching hashes from hydra-plutus?
That would be good but probably orthogonal to this PR's feature?
Something I would have added to this PR is calling this function from the inspect-scripts
executable for all scripts we have. Perhaps even add a specific CI step to automatically generate a profile from saturated scripts?
This is not possible as the scripts themselves are missing concrete datum, redeemer, and script context arguments. To profile scripts we need all of them. Hence, this function which extracts them from the |
I know, but what prevents us from constructing a "Healthy Tx" and extract the fully applied scripts from this tx? |
That would be possible, but we would need to put something like that into the |
|
3d147a5
to
c157418
Compare
This gets ahold of all the applied plutus scripts in a transaction to profile them externally by returning the fully applied, flat-encoded UPLC programs.
e1ec0af
to
996d9f0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor suggestions, feel free to ignore.
|
||
# Profiling Hydra scripts | ||
|
||
This is a quick tutorial how to profile Hydra scripts and is intended for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typos:
a quick tutorial
->a quick tutorial on
and is intended
->, and it is intended
This is a quick tutorial how to profile Hydra scripts and is intended for | ||
contributors to the `hydra-node`. | ||
|
||
On every PR and also for the latest `master`, we do compute typical transaction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: remove transaction
-- [...] | ||
``` | ||
|
||
After running the corresponding code (`tx-cost` in our example), we will be left |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion:
running
tx-cost
executable in our example
|
||
Unfortunately it's quite hard to tell them apart, but script sizes should help | ||
in telling the big `vHead` script apart from the smaller `vCommit` script. In | ||
the profile, names of original `plutus-tx` functions will be retained so that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: so that
-> which
Unfortunately it's quite hard to tell them apart, but script sizes should help | ||
in telling the big `vHead` script apart from the smaller `vCommit` script. In | ||
the profile, names of original `plutus-tx` functions will be retained so that | ||
should make it clear at the latest. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: at the latest
-> which is which
?
upstream projects and use your distribution's package manager): | ||
|
||
``` | ||
nix shell nixpkgs#flamegraph github:input-output-hk/plutus#x86_64-linux.plutus.library.plutus-project-924.hsPkgs.plutus-core.components.exes.traceToStacks github:input-output-hk/plutus#x86_64-linux.plutus.library.plutus-project-924.hsPkgs.plutus-core.components.exes.uplc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: why 924
? Are we not still using ghc 8.10.7
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Plutus is already supporting 9.2.4
and their nix environment is parameterized by it.
This gets ahold of all the applied plutus scripts in a transaction to profile them externally by returning the fully applied, flat-encoded UPLC programs.
This can be seen as the acquiring an executable script step of the plutus-tx profiling guide.
Thoughts when creating this and some usage tips are in the logbook.
With this profiles and flame-graphs of memory/cpu usage of our hydra scripts like this can be made:
Created a page in /benchmarks on our website, explaining steps to profile scripts in the hydra repository and link it from contribution guidelines.
Created an issue to re-expose
mkTermToEvaluate
in latestplutus
version IntersectMBO/plutus#5133