Avoid lambda compilation for member access expressions in LINQ

[bahusoid]

Fixes #2947

Also see #2448 for details and benchmarks.

[bahusoid]

Original code wraps expression in additional lambda to make it compile directly in Func<object> delegate.
But my tests show that direct expression compilation and DynamicInvoke works slightly faster. So just unwrap TargetInvocationException thrown by DynamicInvoke to behave as old code

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19043.1348 (21H1/May2021Update)
Intel Core i5-5200U CPU 2.20GHz (Broadwell), 1 CPU, 4 logical and 2 physical cores
.NET SDK=5.0.201
  [Host]     : .NET 5.0.4 (5.0.421.11614), X64 RyuJIT
  DefaultJob : .NET 5.0.4 (5.0.421.11614), X64 RyuJIT


|        Method |       Mean |     Error |    StdDev | Ratio | RatioSD |
|-------------- |-----------:|----------:|----------:|------:|--------:|
| DynamicInvoke | 183.670 us | 3.5535 us | 3.8022 us | 1.000 |    0.00 |
| WrapAndInvoke | 203.600 us | 1.3428 us | 1.1213 us | 1.106 |    0.02 |
|    Reflection |   1.020 us | 0.0078 us | 0.0070 us | 0.006 |    0.00 |

Source: https://gist.github.com/bahusoid/c68cb6b81f8dde9252d0cc67229136b4

[hazzik]

Reflection what is it? ok, I should have looked the code before asking.

[hazzik]

@bahusoid on my setup WrapAndInvoke is 18% faster than DynamicInvoke

[bahusoid]

Hm... Interesting.. Maybe it's not about setup but target framework? I tested on .NET 5

[razzmatazz]

Hey @bahusoid

Thanks! Still, some questions:

• Will this will come with 6.x and not on 5.x series? (i.e. a long time later?)
• If not on 5.x, then -- will there be a away to backport it?

[bahusoid]

Will this will come with 6.x

It's intended for 5.4. When merged you will be able to test/use it with our dev builds: https://www.myget.org/gallery/nhibernate
AFAIK it's in pretty stable state right now