-
-
Notifications
You must be signed in to change notification settings - Fork 105
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
Add assertion for cpu and memory budget when testing via attributes #1109
Comments
Thank you very much for your answer, didn't know this was possible. It's good to see that there are alternatives and that asserting against cpu/mem costs is an actual necessity. It would be nice to have a more straightforward way of doing it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is your idea? Provide a use case.
Script costs execution are an important aspect of writing contracts on cardano.
In every validator script I've been working on, one of the phases was to optimise costs.
Currently tests already report on their costs, but, afaik, there is no way to assert against them.
Once optimised for resources consumption, it should be possible to ensure that further code modifications, won't unexpectedly blow up resources used during execution. This is even more relevant when migrating from a version to another of aiken. Even for aiken development itsels.
Something like rust attributes could work very nicely as adding assertion within the test could alter cpu/memory used.
Example:
In the example the attribute requires resources to be
equal
to some specific memory and cpu. It could be nice to have to have option to chose between exact values or less than values.Why is it a good idea?
Coz it allows devs to set strong budget constraints for execution costs of specific part of the code, and prevent changes to the code to blow up costs unexpectedly.
What is the current alternative and why is it not good enough?
Check costs in test reports breakdown and compare with previous ones.
The text was updated successfully, but these errors were encountered: