Referencing a NET Standard 2.0 library in a NET Framework 4.8 Project - Performance Issues?

Question

I have a NET Framework 4.8 Winforms application that references a NET Standard 2.0.3 library which uses Entity Framework Core v 2.2.6 to access data.

In the IDE of my development environment, it works like a champ. When I run the EXE directly or run it from my user testing environment, it is unusably slow. So I dug into it a bit and it was my Entity Framework Load() statement. I verified the performance of SQL and it's not what is causing a 15 second delay in loading a form with 30 rows. I think it has to do either with loading the models (not the data) or it's trying to load resources that are available in the IDE but need to be found in the operating system.

My other applications using Net Framework 4.5.2 and data sets/table adapters continue to work fine and I checked the database and it's not the problem (SQL Server). The test environment is on Windows 10 and my workstation has the dev version of NET Core 3.0 and NET Framework 4.8 but the user workstations do not. They are all equally slow.

Can you think of any reason that this stack would choke? Any thoughts/advice would be welcome.

Answer 1

Simply using the NetStandard library shouldn't make any noticable difference to performance. What is most likely to be the issue in that case based on the limited info you've provided, is probably the different environment. Specifically, the testing database is probably slower than your development one.

This may be harder to identify but it's partly due to how EF core 2.2.x loads it's data. In Ef core 3.x the odd behaviour was fixed, but basically the filtering that you do is done client side instead of server side. For example, if you have a table with a million rows and you're selecting 10, EF 2.2.6 will return a million rows fromt the database and discard most of them on the client, whereas EFcore 3 will return the 10 from the database, as it passes the filtering to the server.

Without more information though, we can't really make a good guess.