Home Dashboard Directory Help
Search

System.Array.IStructuralEquatable.GetHashCode Does Not Compute Hash Codes as Intended. by Michael Graczyk


Status: 

Closed
 as Fixed Help for as Fixed


12
0
Sign in
to vote
Type: Bug
ID: 755995
Opened: 7/29/2012 7:01:31 PM
Access Restriction: Public
0
Workaround(s)
view
6
User(s) can reproduce this bug

Description

This is a resubmission of the bug formerly located here:

https://connect.microsoft.com/VisualStudio/feedback/details/529636.

a cached copy can be found here:

http://webcache.googleusercontent.com/search?q=cache:BfWsi7JD3-wJ:https://connect.microsoft.com/VisualStudio/feedback/details/529636+&cd=2&hl=en&ct=clnk&gl=us

The bug is still present in .NET 4.5.

Here is the implemenatation of GetHashCode() in Array.cs (.NET 4.0 ref source):

        int IStructuralEquatable.GetHashCode(IEqualityComparer comparer) {
            if (comparer == null)
                throw new ArgumentNullException("comparer");
            Contract.EndContractBlock();

            int ret = 0;

            for (int i = (this.Length >= 8 ? this.Length - 8 : 0); i < this.Length; i++) {
                ret = CombineHashCodes(ret, comparer.GetHashCode(GetValue(0)));
            }

            return ret;
        }

Clearly, the code:
    ret = CombineHashCodes(ret, comparer.GetHashCode(GetValue(0)));

was intended to be:
ret = CombineHashCodes(ret, comparer.GetHashCode(GetValue(i)));

I say "clearly" because if the intention were to only use the length - 8th value in the computation, the code would not have included a for loop.


Fixing this small typo does not change the execution time of method, does not change the size of the IL, and only increases the size of the JIT'ed code by 2 or 3 bytes.

Similarly, fixing this typo will not break any code unless the code were written to be pathologically dependent on the the behavior of IStructuralEquatable.GetHashCode.



Details
Sign in to post a comment.
Posted by piers7 on 12/19/2013 at 7:48 PM
We tracked a significant performance problem in our system down to this bizarre implementation. We were using a Dictionary<object[],object[]> as a cache, using a StructualEqualityComparer to coalesce 'equivalent' entries. The consequence of this implementation was the dictionary distributed our 180k entries over just 16 buckets, resulting in *extremely* slow dictionary insert/lookup performance.

If I'd wanted a broken hashcode implementation, I'd have written my own :-/
Posted by Microsoft on 7/30/2012 at 1:54 AM
Thank you for submitting feedback on Visual Studio 11 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by Microsoft on 7/29/2012 at 7:53 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.