Improve performance of DecEq deriving
#34
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
WhatisRT
force-pushed
the
andre/derive-deceq-performance
branch
from
ea5f4a2 to
7a2cfc3
Compare
I see ~47% speedup in instance generation time (typechecking) and ~22% speedup at runtime (normalization) with admittedly flaky benchmarks. Crucially, the generated instances should now only ever force booleans during normalization if all we want to know is the boolean equality.
WhatisRT
force-pushed
the
andre/derive-deceq-performance
branch
from
7a2cfc3 to
d459f65
Compare
This improves instance generation time by another ~10% in the existing benchmarks and prevents exponential blowup in constructors with many arguments.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I see ~47% speedup in instance generation time (typechecking) and ~22% speedup at runtime (normalization) with admittedly flaky benchmarks. Crucially, the generated instances should now only ever force booleans during normalization if all we want to know is the boolean equality.
Since this is probably the single most used feature provided by this library, I invite everyone to test if all instances still generate correctly and that there are no performance regressions.
(Also, I realized just now that apparently #33 got merged before I did my improvements to it, so the commits are now in this PR. I don't mind having them tangled so I'll keep it like that for now, but I'll put them in a separate PR if desired).