BenchmarkDotNet | Powerful .NET library | Performance Testing library

From memory, Benchmark.NET will run benchmarks for all frameworks with some internal wizardry. So instead of using the existing preprocessor symbols it's probably better to split your tests across two classes with different RuntimeMoniker attributes. For example:

You can think about it as of adding unit tests for your console app. You don't add the tests to the app itself, but typically create a new project that references (not copies) the logic that you want to test.

In my opinion the best approach would be to:

1. Add a new console app for benchmarks to your solution.
2. In the benchmarks app, add a project reference to the existing console app.
3. Add new benchmarks that have all the BDN annotations to the benchmark project, but implement the benchmarks by referencing public types and methods exposed by your console app. Don't copy the code (over time you might introduce changes to one copy and end up testing outdated version).

Ok, I found a solution. My computer does not have enough RAM to run the given number of benchmark iterations. It was enough to change the benchmark settings to:

This can be done via the ArtifactsPath property in IConfig as explained here

It turned out that the problem was an unnecessary environment variable which pointed to the wrong sdk. After deleting the variable and restarting Visual Studio everything worked out fine.

The IL and JIT ASM certainly don't tell us much. I'm thinking that some CPU/Cache behavior is in play here. Perhaps you are seeing a cost of switching between 128-bit and 256-bit use of the AVX instructions?

VZEROUPPER - Set the upper half of all YMM registers to zero. Used when switching between 128-bit use and 256-bit use.

If you start both your test runs with a single TestStruct2 then perhaps both tests will get a small "set AVX mode" penalty, allowing the TestStruct2 to perform better? Maybe changing the order of the two tests would also yield different results.

Shortly, the difference is coming from the different expressions for pattern parameter of EF.Functions.Like, and the way LINQ to Objects (used by EF Core InMemory provider) processes IQueryable expression tree.

First off, performance test with EF Core InMemory provider against small set of data is irrelevant, since it is measuring basically the query expression tree building, while in the case of real database, most of the time is executing the generated SQL query, returning and materializing the result data set.

Second, regarding

I was worried that I would get a performance hit for using Expressions and a bit of reflection

Both approaches build query expression tree at runtime using Expression class methods. The only difference is that the C# compiler generates that code for you at compile time, thus has no reflection calls. But your code could easily be modified to avoid reflection as well, thus making the generation fully equivalent.

More important difference is that your code is emitting ConstantExpression, while currently C# compiler has no way to generate constant expressions from variables, so it always emits closures, which in turn are bound as query parameters by the EF Core query translator. Which in general is recommended for SQL queries, so you'd better do the same inside your method, or have an option to do so.

So, to recap shortly, your method binds constant expression, and compiler method binds closure. But not only. See here

Check if there is any file that is created/changed but not staged using this command:

The short answer is you cannot run benchmark with the structure you created and it is intentional.

For the BenchmarkDotNet (and it is a generally good practice) it's required for solution to have following structure