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

Shrinking takes an enormous amount of time #267

Closed
dnadales opened this issue Feb 22, 2019 · 4 comments
Closed

Shrinking takes an enormous amount of time #267

dnadales opened this issue Feb 22, 2019 · 4 comments

Comments

@dnadales
Copy link
Member

When a counterexample is found, the shrinking process can take up to 10 minutes. This is not acceptable. We should try to tweak the generators so that the shrinking becomes more efficient. Alternatively, we might have to change our testing approach so that we use state-machine-based testing, instead of generating the whole abstract trace at once.

The first thing to try is to replace the use of frequency:

      Gen.frequency [ (5, return acc)
                    -- The probability of continue with the recursion depends
                    -- on the size parameter of the generator. Here the
                    -- constant factor is determined ad-hoc.
                    , (unSize d * 2, do
                          mStSig <- genSigSt @s env sti aSigGen
                          case mStSig of
                            Nothing ->
                              go d sti acc
                            Just (stNext, sig) ->
                              go d stNext ((stNext, sig): acc)
                      )
                    ]

Since this will generate a very large shrink three. An alternative suggested by @dcoutts is to generate an arbitrary number that determines the trace length, and then generate a trace of that size.

The other thing to try, is generating only valid signals, so that the chance of failure is smaller when composing large generators.

Finally, we might need to incorporate more knowledge of the operational rules into our generators.

@dnadales
Copy link
Member Author

dnadales commented Apr 4, 2019

This will be solved by the work @ruhatch carried out, combining hedgehog state machine models with our STS framework.

@ruhatch
Copy link
Contributor

ruhatch commented Apr 25, 2019

Should be helped by PR #451

@ruhatch ruhatch closed this as completed Apr 25, 2019
@ruhatch
Copy link
Contributor

ruhatch commented May 7, 2019

@dnadales Maybe we should reopen this as you're going to look into Trace shrinking further?

@dnadales
Copy link
Member Author

dnadales commented May 7, 2019

I don't think so. What we will be doing is experimental. The issue was solved by using hedgehog state machine, so whatever proposal results from our experiments with an improved traces generator should take shrinking time into consideration. Does that make sense?

nc6 pushed a commit that referenced this issue May 19, 2020
264: Upgrade cardano-binary to GHC 8.6.3 r=mdimjasevic a=mdimjasevic

This upgrades `cardano-binary` to GHC 8.6.3.

The `tasty-hedhehog` package had to be declared in a `stack.yaml` file.

Closes #263.

267: Upgrade cardano-crypto-wrapper to depend on GHC 8.6.3 r=mdimjasevic a=mdimjasevic

This upgrades `cardano-crypto-wrapper`'s stack build to GHC 8.6.3.

The `tasty-hedhehog` package had to be declared in a `stack.yaml` file.

Closes #265.

Co-authored-by: Marko Dimjašević <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants