Performance compared to EF6.Extended

[ksmithRenweb]

Performance as always is a broad issue but it is the key as to why a query batching library is so useful.
In some cases the queries don't need to be batched. In those cases, performance shouldn't be significantly different.

After that, here are the results of some performance testing. All these calls were averaged over a 100 runs. After running once to make sure the assemblies are loaded. All these calls have multiple joins. All these calls reached out to a sql server out on the network but it was the same db for all the calls. So the latency should be equivalent for all of them.

[JonathanMagnan]

Hello @ksmithRenweb ,

Thank you for reporting this benchmarks, but I'm not sure what you are seeking with this thread.

Is there a question?

Best Regards,

Jonathan

[ksmithRenweb]

Then what I am seeking is that there would not be a significant performance loss when using your future framework. In the case where only a single call query is made, there is a significant performance loss.
There should be a way for you to go, "if only 1 call is batched, skip all this extra logic and let EF Core make the call."

[JonathanMagnan]

Thank you,

That is very clear now ;)

[ksmithRenweb]

I've issued a PR on some changes I authored. The changes eliminate the performance problem.

[JonathanMagnan]

Hello @ksmithRenweb ,

Thank a lot for the help.

Tomorrow I should have enough free time to verify & merge your PR. I will try to make some optimization as well.

Best Regards,

Jonathan

[JonathanMagnan]

Hello @ksmithRenweb ,

The v1.4.26 has been released.

Thank you for your contribution. We removed the need for the interface in your PR, but we kept the rest of your code.

Let me know about new performance. It should be similar to the PR you provided.

Best Regards,

Jonathan

[ksmithRenweb]

Hi Jonathan, Your welcome. I’ll have to review what you did different, see if I can learn anything. When should a new nuget package be realeased? Thanks, Kevin Smith From: Jonathan Magnan [mailto:[email protected]] Sent: Saturday, February 11, 2017 8:38 AM To: zzzprojects/EntityFramework-Plus <[email protected]> Cc: Smith, Kevin <[email protected]>; Mention <[email protected]> Subject: Re: [zzzprojects/EntityFramework-Plus] Performance compared to EF6.Extended (#113) Hello @ksmithRenweb<https://github.com/ksmithRenweb> , The v1.4.26 has been released. Thank you for your contribution. We removed the need for the interface in your PR, but we kept the rest of your code. Let me know about new performance. It should be similar to the PR you provided. Best Regards, Jonathan — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#113 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AWcDMTX8mTz84bSsPfOFRwgIC_6IvSS5ks5rbce2gaJpZM4Lx7hv>.

[ksmithRenweb]

having reading difficulties this morning.
1.4.26 will be reviewed internally today.

[JonathanMagnan]

It's Monday ;)

[ksmithRenweb]

Tested 1.4.28. Performance is similar to my last test.
What amuses me is performance is a little better in some of the cases than base EF Core. Makes me wonder but will probably be a week or two before I go looking for a reason why.

I consider this issue closed.
Have a good week.

[ksmithRenweb]

While looking at the code. I think you need to shift a few lines around to maintain InMemory support.

Currently:
if (Queries.Count == 1)
{
Queries[0].GetResultDirectly();
Queries.Clear();
return;
}

#if EF5 || EF6
var connection = (EntityConnection) Context.Connection;
#elif EFCORE
if (IsInMemory)
{
foreach (var query in Queries)
{
query.ExecuteInMemory();
}
return;
}

So in the case where there is only 1 query and its an in memory. there will be an error.

[JonathanMagnan]

Hello @ksmithRenweb ,

You are right, thank you.

I also added the Queries.Clear() before the return.

What amuses me is performance is a little better in some of the cases than base EF Core

That is often due to how benchmark has been created. Sometimes, only a very small mistake can make the difference.

By example, if you make tests on EF Core before EFE Future, the first call made on EF Core will create and cache the query. All subsequent call (including our library) will use the cached version.

Best Regards,

Jonathan