IntersectMBO / IntersectMBO/plutus

Add test that costing functions are lazy

Open
#6,013 0 comments 0 reactions 0 assignees View on GitHub
Costing Internal status: triaged tech debt
Dominant language
Haskell
Stars
1.6k
Forks
508
Avg merge
3d 10h
Merged PRs (30d)
22

Description

[Migrated from PLT-121]

[This was originally reported by mpj. I'm not sure if it's relevant any more since things have moved on since then.]

In particular, check that they don't call expensive `memoryUsage` functions if they don't need to. I have manually tested that this:

* makes memoryUsage for integer throw an error
* replaced all the cost models for builtins that use integer with mempty, which doesn't look at its arguments
* ran the tests

But it would be good to have an automated test that does something similar so we don't accidentally make them strict (although we'd probably notice in benchmarks).

--------------------------------

@effectfully commented

This is somewhat tested for the builtins machinery and the CK machine as explained in this [Note](https://github.com/input-output-hk/plutus/blob/acedf564b213809d46730af546e8eef178ef944a/plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/ExMemoryUsage.hs), plus we have laziness [Costing](https://github.com/input-output-hk/plutus/blob/acedf564b213809d46730af546e8eef178ef944a/plutus-core/untyped-plutus-core/test/Evaluation/Builtins/Costing.hs) tests, but I’m not sure if those are relevant. We do get a test failure if we accidentally make the costing functions strict for polymorphic builtins, I checked it some time ago.

I do agree it would still be nice to add some dedicated tests, though. Particularly to test some monomorphic builtins as those aren’t covered right now at all, from what I understand.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.