Performance issues with Entity Framework -

Hi Folks,

This has been a burning question and issue with almost all .Net developers -

I also faced this and researched for a long time and have read so many blogs and posts about this issue stating that entity framework is a bottle neck in terms of performance.

Yes, that's absolutely correct if you don't use it properly and without any vision of your DB size and the operations which you would need to perform on the data.

Few important tips -

# Use DBContext wisely as this can completely blow off your application performance.

# DO NOT select all columns and fetch only required columns from tables

# Use relationships intelligently

# Use lazy loading and eager loading wherever required per situation

# Ignore costly queries which fetches too many rows from DB, instead use Stored Procedures if you can

# Identify slow running queries using EF Profiler, this is a very good tool to get the details

# Verify that DB connections are properly closed and disposed

# Verify all DB objects including parameters are being disposed properly

# Use "Using" while using DB connections

# Don't span DBContext for a long time

# Use LINQ properly

# Make use of joins

# Use data filters and fetch limited rows from DB itself rather than filtering them on client side

# Use DB side paging while fetching and displaying large row set

# Don't hesitate using stored procedure wherever needed

# Use views if you have large data in tables

# Tools which be used to fine tune your EF queries - EF profiler, Server dumps, Query debugger, Performance monitors, VS Performance analyzer

# Continuously perform load and performance testing of your application rather than doing it at the end of the project

Happy programming

Should I use ADO.Net Or Entity Framework

Hi Folks,

This has been a topic of many debates, should I use ADO.Net OR Entity Framework?

It really depends on many factors -

1) Performance
2) Speed of Development
3) Neat/Maintainable code
4) Flexibility
5) Learning curve

You gotta select your preferences, lets see these one by one -

First off, if you're starting a new project, go with Entity Framework ("EF") - it now generates much better SQL (more like Linq to SQL does) and is easier to maintain and more powerful than Linq to SQL ("L2S"). I consider Linq to SQL to be an obsolete technology. MS has been very open about not continuing L2S development further.

1) Performance

This is tricky to answer. For most single-entity operations (CRUD) you will find just about equivalent performance with all three technologies. You do have to know how EF and Linq to SQL work in order to use them to their fullest. For high-volume operations like polling queries, you may want to have EF/L2S "compile" your entity query such that the framework doesn't have to constantly regenerate the SQL, or you can run into scalability issues. (see edits)

For bulk updates where you're updating massive amounts of data, raw SQL or a stored procedure will always perform better than an ORM solution because you don't have to marshal the data over the wire to the ORM to perform updates.

2) Speed of Development
In most scenarios, EF will blow away naked SQL/stored procs when it comes to speed of development. The EF designer can update your model from your database as it changes (upon request), so you don't run into synchronization issues between your object code and your database code. The only time I would not consider using an ORM is when you're doing a reporting/dashboard type application where you aren't doing any updating, or when you're creating an application just to do raw data maintenance operations on a database.

3) Neat/Maintainable code

Hands down, EF beats SQL/sprocs. Because your relationships are modeled, joins in your code are relatively infrequent. The relationships of the entities are almost self-evident to the reader for most queries. Nothing is worse than having to go from tier to tier debugging or through multiple SQL/middle tier in order to understand what's actually happening to your data. EF brings your data model into your code in a very powerful way.

4) Flexibility

Stored procs and raw SQL are more "flexible". You can leverage sprocs and SQL to generate faster queries for the odd specific case, and you can leverage native DB functionality easier than you can with and ORM.

5) Learning curve

If you are an ADO.Net developer and ready to learn new techniques then EF would make your life easier by reducing the amount of code you write. If you are a beginner then definitely you can start your learning from EF since this is the present and future.

5) Overall

Don't get caught up in the false dichotomy of choosing an ORM vs using stored procedures. You can use both in the same application, and you probably should. Big bulk operations should go in stored procedures or SQL (which can actually be called by the EF), and EF should be used for your CRUD operations and most of your middle-tier's needs. Perhaps you'd choose to use SQL for writing your reports. I guess the moral of the story is the same as it's always been. Use the right tool for the job. But the skinny of it is, EF is very good nowadays. Spend some real time reading and understanding it in depth and you can create some amazing, high-performance apps with ease.

EF 5 simplifies this part a bit with auto-compiled LINQ Queries, but for real high volume stuff, you'll definitely need to test and analyze what fits best for you in the real world.