-
Notifications
You must be signed in to change notification settings - Fork 99
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
[WIP] Use unboxed sums for change / no-change tracking #461
base: master
Are you sure you want to change the base?
Conversation
then NoChange | ||
else Changed (Leaf h (L k x)) | ||
else Changed $ collision h l (L k x) | ||
| otherwise = Changed $ runST (two s h k x hy t) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that we're less lazy in the result of two
now, and that this is the actual source of the minor performance improvements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should try to make two
itself more strict: Force the result of the recursive application of go
, force the return
ed BitmapIndexed
nodes.
With the benchmarks I'm getting a lot of noise and a rather reliable 2-3% speedup in |
The last time I experimented with this idea, the performance was worse, but maybe things have changed. Or maybe there are differences between |
FWIW, I think those old experiments used unboxed tuples with |
…instead of pervasive
ptrEq
.