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

Make CLB back-end fast enough for fuzzing #60

Closed
3 of 4 tasks
uhbif19 opened this issue Apr 28, 2024 · 1 comment
Closed
3 of 4 tasks

Make CLB back-end fast enough for fuzzing #60

uhbif19 opened this issue Apr 28, 2024 · 1 comment
Labels
backends enhancement New feature or request

Comments

@uhbif19
Copy link
Contributor

uhbif19 commented Apr 28, 2024

Now one Tx sending for Registry takes around 0.1 seconds. This is way to much for fuzzing, we need numbers like 0.01 or 0.001.

Profiling shows that 25% is taken up mkShelleyGlobals in CLB (can be cached), 40% is for makeTransactionBodyAutoBalance and 21% is taken for applySTSOptsEither (real Ledger work) .

So, theoretically around 80% may be dropped with CLB. This might be okay for small and slow fuzzing about 100-1000 examples. For more we probably should use custom Ledger emulator instead of CLB. Seems like applySTS slow performance seem to be real, it does not seem to be only covered by Plutus (?%) or crypto (2.4%) .

TODO:

  • Profile CLB performance
  • Check CLB performance is improved by -O
  • Support without calling makeTransactionBodyAutoBalance and not enforcing Tx fee
  • Decide if to create custom Emulator for such cases of CLB

FYI @euonymos

@uhbif19 uhbif19 added enhancement New feature or request backends labels Apr 28, 2024
@uhbif19 uhbif19 closed this as completed May 28, 2024
@uhbif19
Copy link
Contributor Author

uhbif19 commented May 28, 2024

Actually real QD works in reasonable time, I am not sure why. >3k actions are done in ~100 seconds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backends enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant