Let the list instance fuse #99
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #76, CC @treeowl.
To measure performance of
someFuncHaskell benchmarks often employ code like this:Here we want to measure time of 1000 applications of
someFunc, and in order to do so wedeepseqthe entire listmap someFunc [1..1000]. However, in this scenario we are not really interested in materializing the list: ifsomeFuncis relatively fast, allocations are likely to skew measurements. See Bodigrim/tasty-bench#48 (comment) for discussion and various hacky workarounds.We can do better by making
instance NFData [a]able to fuse by rewriting it viafoldr. This has a nice side effect of avoiding manual recursion and having a more concise definition as well.Before the patch
compiles to
Here one can observe
$wgo3which is forcing a list (essentially this isrnffrominstance NFData [a]) andgo3_a8hFwhich produces it. Such code allocates boxedIntand(:)constructors.After the patch:
Here we do force evaluation of all elements of the list, but do not allocate them.