Skip to content
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

Constant value handling in ExpressionEqualityComparer #29006

Open
roji opened this issue Sep 7, 2022 · 0 comments
Open

Constant value handling in ExpressionEqualityComparer #29006

roji opened this issue Sep 7, 2022 · 0 comments

Comments

@roji
Copy link
Member

roji commented Sep 7, 2022

#28581 was filed since array constants in query trees weren't compared correctly (hash code calculation, equality); this led to a cache miss for every query that contained an array literal, leading to continuous costly recompilation.

While #28720 fixed this specifically array literals (and tuples, or anything else that implements IStructuralEquatable), we still have this issue for constants of other types: lists, dictionaries, and possibly others (any type where Equals and GetHashCode aren't implemented for structural/value comparison). While constants of these are likely to be much rarer than array constants, we should consider fixing them as well.

On a related note, we may want to exclude constant values from the hash code calculation, and only include e.g. their CLR type. This would be an optimization as we no longer need to do potentially costly hash code calculations, and the expression tree shape and the constant type should provide enough hash code distribution. The theoretical downside is that all expressions which vary only by a constant value get the same hash code, and therefore would be stored under the same dictionary bucket. But that should only meaningfully occur when users erroneously build expression trees with constants instead of parameters (this).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants