EquivalencyValidator performance fixes

[pentp]

This fixes GenericDictionaryEquivalencyStep and GenericEnumerableEquivalencyStep performance problems caused by the use of uncached LambdaCompiler.Compile which is very expensive.
Related to #475.

This makes ObjectAssertions.BeEquivalentTo about 4.3x faster in our test projects.

[jnyrup]

Thanks for taking a look at this part of the code base and submitting a PR.
I find it a bit difficult to review the changes, as they cover many different parts, more than just replacing the LambdaCompiler.

Can you comment more the effects the individual changes had?
E.g. you added several conditionals to avoid calls to ForCondition and I'm interested in the real world benefits of these.

What were the absolute improvements on your tests?

@adamvoss As far as I could trace this back, you authored the initial implementation of this.
Do you recall any considerations in picking LambdaCompiler approach over MakeGenericMethod?

[pentp]

The conditionals before ForCondition calls are just short-circuiting the check and FailWith - this avoids a bunch of unnecessary work for the common case.
ObjectReference changes are also optimizations for the common case (no cyclic references).

For one class of tests the absolute improvement was from 17 to 13 seconds, but I don't have data for all our tests (this includes everything, e.g. starting up testhost.exe). BeEquivalentTo improved from 5391ms to 1248ms.

[jnyrup]

As you see from my comments, I'm really interested in what differences the different parts make.
Do you have a test case you can share?

For inspiration have a look at #817 (comment) where I extracted the relevant changes into eight separated commits, so I could run isolated benchmarks against them.

[jnyrup]

❓ I guess you saw that getting HashCode of the old path array, didn't make much sense.
Can you comment on why you chose RuntimeHelpers.GetHashCode over Object.GetHashCode()?

[pentp]

Because we want to compare/hash the object reference not value. RuntimeHelpers.GetHashCode returns the object identity hash even if it overrides Object.GetHashCode.
I'm not sure if this is even used anywhere, it looks like ObjectReference is only used in lists.

[jnyrup]

I tried a dig a bit in the git history to get some context:

• ObjectReference was added in 5e6d9ee4 where it had a (to me) sensible GetHashCode.
• It was changed in 02e71b30 from string propertyPath to string[] path, but GetHashCode was not updated.
• probably due to that, perf optimization of ShouldAllBeEquivalentTo for large collections #395 did not work as ObjectReferences are now stored in HashSet.
• Undone a breaking change in the way the object tracker works. #399 reverted that PR.

[jnyrup]

@pentp Please let me know if I can be of any help.

If you split the PR into more isolated commits, such as e.g.

• Replacing Expression.Lambda(),Compile() with MakeGenericMethod
• is ICollection return early check
• lazy splitting of path in ObjectReference
• Replacing SequenceEqual with C-style loop in ObjectReference
• Changing GetHashCode() in ObjectReference
• subject != null || , expectation != null || and if (interfaceTypes.Length != 1) conditionals

I'll try to setup some benchmarks to get some numbers.

[dennisdoomen]

Hi @pentp, do you think you'll be able to follow up?

[pentp]

Yes, I planned to check up on this PR this week, so hopefully tomorrow. I have some measurements saved, just need to check which changes gave only minor improvements and probably just undo those.

[jnyrup]

@pentp This looks very nice!
Is this still WIP?

[pentp]

No, this should be ready for merge.

[dennisdoomen]

Needs to be rebased

[adamvoss]

Thanks for taking a look at this part of the code base and submitting a PR.
I find it a bit difficult to review the changes, as they cover many different parts, more than just replacing the LambdaCompiler.

Can you comment more the effects the individual changes had?
E.g. you added several conditionals to avoid calls to ForCondition and I'm interested in the real world benefits of these.

What were the absolute improvements on your tests?

@adamvoss As far as I could trace this back, you authored the initial implementation of this.
Do you recall any considerations in picking LambdaCompiler approach over MakeGenericMethod?

Hi, I'm Dan Voss -- Adam's dad. I found this question while wrapping up Adam's digital accounts. I regret to inform you that Adam died in July. http://schluterbalikfuneralhome.com/obituary/adam-voss

[dennisdoomen]

Hi, I'm Dan Voss -- Adam's dad. I found this question while wrapping up Adam's digital accounts. I regret to inform you that Adam died in July. http://schluterbalikfuneralhome.com/obituary/adam-voss

Don't know what to say....

[pentp]

Rebased

[adamvoss]

Hi, I'm Dan Voss -- Adam's Dad. I've only recently gotten access to his e-mail and see that a question was posed to him in this thread. I'm sorry to inform you that Adam died in July -- which is why you haven't had any response.

…

On Tue, Nov 20, 2018 at 4:17 AM Dennis Doomen ***@***.***> wrote: Merged #935 <#935> into master. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#935 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA67P4RDisugkobPPpuEuML0Ix-l0Y-_ks5uw9augaJpZM4XEIHi> .