Speed up equality; remove expensive invariant #43
Conversation
treeowl
force-pushed
the
no-beats
branch
3 times, most recently
from
8fefbb8 to
2d971b8
Compare
We used to define `==` to test equality in *priority* order. This was expensive in and of itself, since it takes logarithmic time to produce each entry. But the situation was worse than that: since priorities are not unique, we introduced an extra invariant to make sure that keys with the same priority are extracted in key order. This requires additional comparisons in various performance-critical functions. * Remove the extra invariant. * Remove the extra code to preserve it. * Change `(==)` to work in key order instead of priority order. Keys are unique, so this is very natural. * Remove a bunch of now-redundant constraints. * Document the newly introduced nondeterminism.
|
@jaspervdj, do you want to go this way? If not, I guess I can open a PR that just changes the |
|
Thanks for looking into this @treeowl! I am definitely fine changing the I'm a bit more worried about changing the Do you have any benchmark data laying around? What sort of speedups are we talking about? |
|
No, I don't have data, but I can try to get some. |
We used to define
==to test equality in priority order. This was expensive in and of itself, since it takes logarithmic time to produce each entry. But the situation was worse than that: since priorities are not unique, we introduced an extra invariant to make sure that keys with the same priority are extracted in key order. This requires additional comparisons in various performance-critical functions.(==)to work in key order instead of priority order. Keys are unique, so this is very natural.