Performance drops on Visual Studio 2017

[Gabbbou]

I integrated Effort.EF6 to our solution. Using Resharper to run my tests, all 700 tests ran in 5 minutes. Which is good. Then, I ran the tests using the test runner from Visual Studio 2017 and it took 45 minutes to run all the tests.

After some profiling I discovered that the lines being slow are the ones where we save changes on context.
Adding and saving a small collection of objects with Resharper takes around 10 ms, when on VS test runner is takes 60 ms.

I use EF6 model first. I create a transient connection before each tests:
_dbConnection = Effort.EntityConnectionFactory.CreateTransient("name=MyEntities");
DataContext = new MyEntities(_dbConnection);

I use Visual Studio Enterprise 2017 Version 15.5.2 .NEt Framework Version 4.6.01590

[Gabbbou]

Just tested with VS2015 and it takes 25mins... I'm so confuse.,,

[JonathanMagnan]

Hello @Gabbbou ,

Honestly, I'm not sure what we can do here.

It seems more an issue about how Unit Test are handled in VS2015, VS2017, and Resharper than an issue with the library.

Best Regards,

Jonathan

---

Help us to support this library: Donate

[Gabbbou]

Hi!

I understand how it may appear as a problem from the Visual Studio runner.
That being said, we also have a big test suite not touching the database that is as fast on VS as on Resharper.
No unit test, not using an external dependancy, takes a long time using VS test runner. No one could use the tool if it was the case.

Also, Effort is built for EF whih is for C# and I guess most poeple use VS for C#. The lib being that slow makes it unusable. Will it be like that for every futur version of VS? I don't know, but if it's the case...

We also have this problem on our build machine and other dev setup.

Thanks !

[JonathanMagnan]

Hello @Gabbbou ,

We will look at it to check if we can find something. Giving a try worth it ;)

Best Regards,

Jonathan

---

Help us to support this library: Donate

[Gabbbou]

I will give you news of my investigations. For now, it's really when we do the context.SaveChanges() that takes time.

Small question: When you add to a collection and SaveChanges, is it only the InsertCommandAction.ExecuteDataReader that is called?

[JoeShmoel]

Gabbbou, did you find a solution to Efforts poor performance?

[JonathanMagnan]

Hello @Gabbbou , @JoeShmoel ,

We recently released the v1.3.8'

In this version, we added a new method ClearTables that clear all data and reset the identity. Only the __migrationHistory tables keep his data. So it allows to speed up test by A LOT when you re-use the same connection.

var connection = (EffortConnection)DbConnectionFactory.CreateTransient();

// ...code...

connection.ClearTables();

If you have the chance to try it, could you let me know if you still have the issue?

Best Regards,

Jonathan

[fsdschmidt]

We have also big performance issues since vs 2017. We use the EntityConnectionFactory where the EffortConnection is encapsulated. And we dispose our EntityConnection in every test with using block and so the EffortConnection is also disposed. But I updated to v1.3.9 and tested what will happen if our DB readonly tests uses a static shared connection. Unfortunately it has no performance impact to re-use the same connection between tests.

[JonathanMagnan]

Hello @fsdschmidt ,

Could you provide us an example of how you use it? We made some test on our side and got a huge impact.

Best Regards,

Jonathan

[Gabbbou]

Updated to 1.3.9, it now takes 3mins instead of 45mins. Good Job!

Thats being said, the method "clearTables" doesn't exists on "Effort.EntityConnectionFactory.CreateTransient". Seems like I don't even need it.

Thanks!

[JonathanMagnan]

Hello @Gabbbou ,

The ClearTables method exists on the EffortConnection

The Effort.EntityConnectionFactory.CreateTransient create an EntityConnection, that's why you don't see it.

You can use this code to retrieve it

var effortConnection = (Effort.Provider.EffortConnection)entitiyConnection.StoreConnection;
effortConnection.ClearTables();

I'm not sure why you get so high-performance improvement without ClearTables. Perhaps something else that has been fixed from another issue.

Best Regards,

Jonathan

[pauliusg]

Hi @JonathanMagnan,

I have tried to use effortConnection.ClearTables() but now I have other issue, I use CsvDataLoader to preload some data, after calling ClearTables that data is removed too. What can you suggest to put that data back after ClearTables?

[JonathanMagnan]

Hello @pauliusg ,

We will look at it if there is a way for us to keep seeded data.

[Gabbbou]

It might be an update from VS. In both case, performance is there so I'm happy.