-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
ast: hash containers on insert/update #4367
ast: hash containers on insert/update #4367
Conversation
a25ab26
to
5d0be95
Compare
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.
This looks good to me. I do remember being concerned at some point about the cost of doing all the hashing proactively but I would expect we never construct these containers unless we actually compare them with high probability. Did you see any significant change in benchmarks? Either way, computing the hashes within functions mutating the containers seems cleaner design that making making the hashing after mutation concurrent safe.
5d0be95
to
a9a8d35
Compare
This allows us to use the Hashes for comparisons, too, since they're cheaply available all the time. Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
a9a8d35
to
857c80a
Compare
I'm about to get this merged. Benchmarking ast, pr (new) against main (old), we find (benchstat):
I'm a little surprised about the many negative changes (= stuff getting better), but at least it makes the +20% acceptable; and |
With this change, we'll calculate hashes as soon as we create or update arrays/sets/objects. This way, we avoid the race detected in #4345 when using PrepareForEval.
❓ Any catastrophic consequences I haven't foreseen?
Fixes #4345.