Linq to SQL and Entity Framework performance comparison and optimization

Linq to SQL and Entity Framework performance comparison and optimizationAlexander KonduforovEmail: alexander.konduforov@gmail.comWeblog: www.merle-amber.blogspot.com

Alexander KonduforovEmail: alexander.konduforov@gmail.comWeblog: www.merle-amber.blogspot.com

GoalsGoals

explain the L2S and EF architectures give an understanding of performance losses

and bottlenecks describe the possible ways of performance

improvements check the real benefits of the performance

improvements analyze the results, give advices

explain the L2S and EF architectures give an understanding of performance losses

and bottlenecks describe the possible ways of performance

improvements check the real benefits of the performance

improvements analyze the results, give advices

General ORM architectureGeneral ORM architecture

Objects providerObjects provider

Query

Records

Data

Objects

SQL

Database providerDatabase provider

DatabasesDatabases

Databases

Query

MappingMapping

Linq to SQL architectureLinq to SQL architecture

Linq to SQL Data ContextLinq to SQL Data Context

LINQ

Records

Data

IEnumerable<T>SQL

SQL

LINQ

Linq to SQL Data ProviderLinq to SQL Data Provider

MS SQL Server

SQL

Entity Framework architecture

Entity Framework architecture

ADO.NET Data ProvidertADO.NET Data ProvidertADO.NET Data ProviderADO.NET Data ProviderADO.NET Data ProviderADO.NET Data Provider

Object ServicesObject Services

LINQ to EntitiesLINQ to Entities

CCT

xDataReader

DBDataReader

IEnumerable<T>ESQL

CCT

ESQL

LINQ

EntityClient Data ProviderEntityClient Data Provider

Internal caching mechanisms

Internal caching mechanisms

Context metadata, etc. (app-domain level) Materialized objects (context level, first level

cache) EntitySQL queries (app-domain level) Linq queries (when compiled only) ADO.NET providers internal caching No second level caching like in NHibernate

Context metadata, etc. (app-domain level) Materialized objects (context level, first level

cache) EntitySQL queries (app-domain level) Linq queries (when compiled only) ADO.NET providers internal caching No second level caching like in NHibernate

Main performance lossesMain performance losses

Infrastructure initialization Mapping overhead (inheritance, complex

mapping) Query analysis SQL generation Materialization

Infrastructure initialization Mapping overhead (inheritance, complex

mapping) Query analysis SQL generation Materialization

Performance considerationsPerformance

considerations

Views pre-generation (EF only) Tracking vs. no tracking Objects materialization and context-level

caching Linq queries compilation Linq to Entities vs. EntitySQL (EF only) Lazy vs. eager loading Data modification SQL generation

Views pre-generation (EF only) Tracking vs. no tracking Objects materialization and context-level

caching Linq queries compilation Linq to Entities vs. EntitySQL (EF only) Lazy vs. eager loading Data modification SQL generation

Tests suite and toolsTests suite and tools

Northwind database (yeah!)

Data retrieval tests: simple data retrieval advanced data retrieval (lazy loading) advanced data retrieval (optimal)

Data modification tests simple modification (10) advanced modification (with relations, 10) heavy modification (1000)

Northwind database (yeah!)

Data retrieval tests: simple data retrieval advanced data retrieval (lazy loading) advanced data retrieval (optimal)

Data modification tests simple modification (10) advanced modification (with relations, 10) heavy modification (1000)

Initialization and views pre-generation

Initialization and views pre-generation

Context data (metadata, etc.) are cached in the app-domain

Connections are opened when needed Views can be pre-generated for EF: EdmGen.exeUse it to avoid cold start

Context data (metadata, etc.) are cached in the app-domain

Connections are opened when needed Views can be pre-generated for EF: EdmGen.exeUse it to avoid cold start

Data Access

Readers L2S EF

Time, ms. 12 38 207

Tracking vs. no trackingTracking vs. no tracking

Tracking is used for: Identity Map for the materialized objects tracking changes of the materialized objects

No Tracking can be used: when you don’t need to modify objects

Tracking is used for: Identity Map for the materialized objects tracking changes of the materialized objects

No Tracking can be used: when you don’t need to modify objects

Data Access

Readers L2S L2S (no tracking)

EF EF (no tracking)

Simple 20 23 20 50 25

Advanced (lazy)

33 98 30 140 138

Advanced (optimal)

23 83 79 88 61

Objects materialization and context-level caching

Objects materialization and context-level caching

Materialization is: creation of the objects in memory cost-expensive (40-70% of the query)

Created objects are saved in the context (when Tracking)

To create context for every query or to use the same context for few queries? What is better?

Materialization is: creation of the objects in memory cost-expensive (40-70% of the query)

Created objects are saved in the context (when Tracking)

To create context for every query or to use the same context for few queries? What is better?

Data Access

Readers

L2S (many)

L2S (one) EF (many)

EF (one)

Simple 23.3 23.8 13.8 54.1 36.1

Advanced (lazy)

35.2 107.4 36.6 148 54.5

Advanced (optimal)

24.2 79.2 77.9 79.8 76.9

Linq queries compilationLinq queries compilation

EntitySQL queries are cachedLinq to Entities queries are not cached

Every Linq query can be compiled and thus “cached”

EntitySQL queries are cachedLinq to Entities queries are not cached

Every Linq query can be compiled and thus “cached”

Data Access

L2S L2S (compiled)

EF EF (compiled)

Simple 23 21 48 42

Advanced (lazy)

102 97 137 109

Advanced (optimal)

85 63 82 42

Linq to Entities vs. EntitySQLLinq to Entities vs. EntitySQL

What is better to use and when?

Linq to Entities: type safety easy-to-use, code completion

What is better to use and when?

Linq to Entities: type safety easy-to-use, code completion

EntitySQL: similar to SQL, flexible low level => faster

EntitySQL: similar to SQL, flexible low level => faster

Data Access Linq to Entities

Linq to Entities (compiled)

EntitySQL

Simple 48 42 44

Advanced (lazy)

137 109 98

Advanced (optimal)

82 42 32

Lazy vs. eager loadingLazy vs. eager loading

Eager loading is resource-consuming Lazy loading is time-consuming

L2S has implicit lazy loading built-inEF has explicit lazy loading built-in

It is always a dilemma… Get what you really need!

Eager loading is resource-consuming Lazy loading is time-consuming

L2S has implicit lazy loading built-inEF has explicit lazy loading built-in

It is always a dilemma… Get what you really need!

Data Access

L2S L2S (compiled)

Linq to Entities

Linq to Entities (compiled)

EntitySQL

Advanced (lazy)

102 97 137 109 98

Advanced (eager)

85 63 82 42 32

Data modificationData modification

L2S and EF contexts are Units of Work:get => change => save all

Only when tracked

L2S and EF contexts are Units of Work:get => change => save all

Only when tracked

Data Modification

Commands L2S EF

Simple 42 153 52

Advanced 75 268 156

Heavy 2,285 12,075 2,952

SQL generationSQL generation

Get your SQL profilers ready!

Get your SQL profilers ready!

Queries Readers/Commands

L2S EF

Simple retrieval 33% 33% 33%

Advanced retrieval (lazy) N/A N/A N/A

Advanced retrieval (optimal)

21% 55% 24%

Simple modification 33% 33% 33%

Advanced modification N/A N/A N/A

Heavy modification N/A N/A N/A

Performance advicesPerformance advices

choose the appropriate data access technology make views pre-generation when possible use the context as long as possible but be aware

of memory overload and concurrency issues turn off tracking when it can be done use Linq queries compilation for complex queries use eager loading when you know what you need

to get use EntitySQL for most time-cost operations be careful with data modification do not afraid to check the generated SQL,

consider using indexes when possible

choose the appropriate data access technology make views pre-generation when possible use the context as long as possible but be aware

of memory overload and concurrency issues turn off tracking when it can be done use Linq queries compilation for complex queries use eager loading when you know what you need

to get use EntitySQL for most time-cost operations be careful with data modification do not afraid to check the generated SQL,

consider using indexes when possible

Q&AQ&A

Go ahead!Go ahead!

Useful linksUseful links

http://msdn.microsoft.com/en-us/library/cc853327.aspx http://blogs.msdn.com/adonet/archive/2008/03/27/ado-net-

entity-framework-performance-comparison.aspx http://blogs.msdn.com/adonet/archive/

2006/08/21/710862.aspx http://blogs.msdn.com/adonet/archive/2007/02/14/entity-

client.aspx http://blogs.msdn.com/adonet/archive/2007/05/30/

entitysql.aspx http://blogs.msdn.com/adonet/ http://mtaulty.com/CommunityServer/blogs/

mike_taultys_blog/archive/2007/08/03/9558.aspx http://oakleafblog.blogspot.com/2007/08/mike-taulty-

compares-linq-to-sql-and.html http://blogs.msdn.com/ricom/archive/2007/06/22/dlinq-linq-to-

sql-performance-part-1.aspx http://www.code-magazine.com/article.aspx?

quickid=0712042&page=1 http://msdn.microsoft.com/ru-ru/magazine/cc163399.aspx

http://msdn.microsoft.com/en-us/library/cc853327.aspx http://blogs.msdn.com/adonet/archive/2008/03/27/ado-net-

entity-framework-performance-comparison.aspx http://blogs.msdn.com/adonet/archive/

2006/08/21/710862.aspx http://blogs.msdn.com/adonet/archive/2007/02/14/entity-

client.aspx http://blogs.msdn.com/adonet/archive/2007/05/30/

entitysql.aspx http://blogs.msdn.com/adonet/ http://mtaulty.com/CommunityServer/blogs/

mike_taultys_blog/archive/2007/08/03/9558.aspx http://oakleafblog.blogspot.com/2007/08/mike-taulty-

compares-linq-to-sql-and.html http://blogs.msdn.com/ricom/archive/2007/06/22/dlinq-linq-to-

sql-performance-part-1.aspx http://www.code-magazine.com/article.aspx?

quickid=0712042&page=1 http://msdn.microsoft.com/ru-ru/magazine/cc163399.aspx