Closed qazxcdswe123 closed 4 months ago
[!IMPORTANT]
Review skipped
Auto reviews are disabled on this repository.
Please check the settings in the CodeRabbit UI or the
.coderabbit.yaml
file in this repository. To trigger a single review, invoke the@coderabbitai review
command.You can disable this status message by setting the
reviews.review_status
tofalse
in the CodeRabbit configuration file.
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Totals | |
---|---|
Change from base Build 1604: | 0.0% |
Covered Lines: | 2347 |
Relevant Lines: | 2648 |
IMO, storing the hash value in an entry can provide a fast equality check. By first comparing hash values before checking key equality, we can prevent perf degradation caused by a poorly implemented key equality check. The downside is a higher memory footprint.
By first comparing hash values before checking key equality
self.hash == other.hash && self.key == other.key
For a && b
, we will need to evaluate both a and b (short circuit), unless what you mean is same_hash || same_key
, but what if two different key hashed to the same hash?
As for poorly implemented key equality check, I guess it is kinda inevitable if we are comparing them?
what do you think?
If a evaluate to false then b will not be evaluated and the whole expression is false. Please correct me if I'm wrong.
I see, that is a consideration. You are right.
Closing for now
If two keys are the same, we can safely assume that they hash to the same hash, so the
hash
field is not necessary.