-
Notifications
You must be signed in to change notification settings - Fork 23.5k
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
maybe an optimizable point for zadd operation #5179
Comments
Very interesting optimization! I just wrote an implementation, stress testing it and committing tomorrow. |
When the element new score is the same of prev/next node, the lexicographical order kicks in, so we can safely update the node in place only when the new score is strictly between the adjacent nodes but never equal to one of them. Technically speaking we could do extra checks to make sure that even if the score is the same as one of the adjacent nodes, we can still update on place, but this rarely happens, so probably not a good deal to make it more complex. Related to #5179.
P.S. Just pushed on |
UPDATE: I'm merging the change, because I can measure a speed boost of more than 10% in an use case which is not even optimal to stress the optimization well enough, so it looks like it's worth it. Thanks @pyloque for the hint. |
When the element new score is the same of prev/next node, the lexicographical order kicks in, so we can safely update the node in place only when the new score is strictly between the adjacent nodes but never equal to one of them. Technically speaking we could do extra checks to make sure that even if the score is the same as one of the adjacent nodes, we can still update on place, but this rarely happens, so probably not a good deal to make it more complex. Related to #5179.
When the element new score is the same of prev/next node, the lexicographical order kicks in, so we can safely update the node in place only when the new score is strictly between the adjacent nodes but never equal to one of them. Technically speaking we could do extra checks to make sure that even if the score is the same as one of the adjacent nodes, we can still update on place, but this rarely happens, so probably not a good deal to make it more complex. Related to redis#5179.
hello da lao |
nice! |
👍 |
🐂 |
i see the code that implements it is already merged. closing. |
👍 |
👍 |
When the element new score is the same of prev/next node, the lexicographical order kicks in, so we can safely update the node in place only when the new score is strictly between the adjacent nodes but never equal to one of them. Technically speaking we could do extra checks to make sure that even if the score is the same as one of the adjacent nodes, we can still update on place, but this rarely happens, so probably not a good deal to make it more complex. Related to redis#5179.
When we use zadd command to update the score for exists value,if the score delta is small,element rank will be no change,i think we only need change the score, while deleting and reinserting is unnecessary.
To be sure the rank is not changed, we can use current node's forward and backward pointer to access the sibling nodes, to test whether the new score is still between the score of prev and next node.
The following source code is clipped from current redis repo.
The text was updated successfully, but these errors were encountered: