Linq to SQL and   Entity Framework performance comparison and optimization Alexander Konduforov Email: alexander.konduforov@gmail.com Weblog: www.merle-amber.blogspot.com
Goals 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 architecture Objects provider Query Records Data Objects SQL Database provider Databases Databases Databases Query Mapping
Linq to SQL architecture Linq to SQL Data Context LINQ Records Data IEnumerable<T> SQL SQL LINQ Linq to SQL Data Provider MS SQL Server SQL
Entity Framework architecture ADO.NET Data Providert ADO.NET Data Provider ADO.NET Data Provider Object Services LINQ to Entities CCT xDataReader DBDataReader IEnumerable<T> ESQL CCT ESQL LINQ EntityClient Data Provider
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
Main performance losses Infrastructure initialization Mapping overhead (inheritance, complex mapping) Query analysis SQL generation Materialization
Performance 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
Tests 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)
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.exe Use it to avoid cold start 207 38 12 Time, ms. EF L2S Readers Data Access
Tracking 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 61 138 25 EF (no tracking) 79 30 20 L2S (no tracking) 140 98 33 Advanced (lazy) 88 50 EF 83 23 Advanced (optimal) 23 20 Simple L2S Readers Data Access
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? 76.9 54.5 36.1 EF (one) 77.9 36.6 13.8 L2S (one) 148 107.4 35.2 Advanced (lazy) 79.8 54.1 EF (many) 79.2 24.2 Advanced (optimal) 23.8 23.3 Simple L2S (many) Readers Data Access
Linq queries compilation EntitySQL queries are cached Linq to Entities queries are not cached Every Linq query can be compiled and thus “cached” 42 109 4 2 EF (compiled) 63 97 21 L2S (compiled) 137 102 Advanced (lazy) 82 48 EF 85 Advanced (optimal) 23 Simple L2S Data Access
Linq to Entities vs. EntitySQL 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 32 98 44 EntitySQL 42 109 4 2 Linq to Entities (compiled ) 137 Advanced (lazy) 82 48 Linq to Entities Advanced (optimal) Simple Data Access
Lazy vs. eager loading Eager loading is resource-consuming Lazy loading is time-consuming L2S has implicit lazy loading built-in EF has explicit lazy loading built-in It is always a dilemma… Get what you really need! 85 102 L2S 63 97 L2S (compiled) 32 98 EntitySQL 42 109 Linq to Entities (compiled ) 137 Advanced (lazy) 82 Linq to Entities Advanced (eager) Data Access
Data modification L2S and EF contexts are Units of Work: get => change => save all Only when tracked 2,952 156 52 EF 12,075 268 153 L2S 75 Advanced 2,285 42 Commands Heavy Simple Data Modification
SQL generation Get your SQL profilers ready! 33% 33% 33% Simple retrieval N/A N/A N/A Advanced retrieval (lazy) 24% 55% 21% Advanced retrieval (optimal) N/A N/A 33% EF N/A N/A 33% L2S N/A Advanced modification N/A 33% Readers/ Commands Heavy modification Simple modification Queries
Performance 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
Q&A Go ahead!
Useful 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

Ling to SQL and Entity Framework performance analysis

  • 1.
    Linq to SQLand Entity Framework performance comparison and optimization Alexander Konduforov Email: alexander.konduforov@gmail.com Weblog: www.merle-amber.blogspot.com
  • 2.
    Goals explain theL2S 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
  • 3.
    General ORM architectureObjects provider Query Records Data Objects SQL Database provider Databases Databases Databases Query Mapping
  • 4.
    Linq to SQLarchitecture Linq to SQL Data Context LINQ Records Data IEnumerable<T> SQL SQL LINQ Linq to SQL Data Provider MS SQL Server SQL
  • 5.
    Entity Framework architectureADO.NET Data Providert ADO.NET Data Provider ADO.NET Data Provider Object Services LINQ to Entities CCT xDataReader DBDataReader IEnumerable<T> ESQL CCT ESQL LINQ EntityClient Data Provider
  • 6.
    Internal caching mechanismsContext 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
  • 7.
    Main performance lossesInfrastructure initialization Mapping overhead (inheritance, complex mapping) Query analysis SQL generation Materialization
  • 8.
    Performance considerations Viewspre-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
  • 9.
    Tests suite andtools 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)
  • 10.
    Initialization and viewspre-generation Context data (metadata, etc.) are cached in the app-domain Connections are opened when needed Views can be pre-generated for EF: EdmGen.exe Use it to avoid cold start 207 38 12 Time, ms. EF L2S Readers Data Access
  • 11.
    Tracking vs. notracking 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 61 138 25 EF (no tracking) 79 30 20 L2S (no tracking) 140 98 33 Advanced (lazy) 88 50 EF 83 23 Advanced (optimal) 23 20 Simple L2S Readers Data Access
  • 12.
    Objects materialization andcontext-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? 76.9 54.5 36.1 EF (one) 77.9 36.6 13.8 L2S (one) 148 107.4 35.2 Advanced (lazy) 79.8 54.1 EF (many) 79.2 24.2 Advanced (optimal) 23.8 23.3 Simple L2S (many) Readers Data Access
  • 13.
    Linq queries compilationEntitySQL queries are cached Linq to Entities queries are not cached Every Linq query can be compiled and thus “cached” 42 109 4 2 EF (compiled) 63 97 21 L2S (compiled) 137 102 Advanced (lazy) 82 48 EF 85 Advanced (optimal) 23 Simple L2S Data Access
  • 14.
    Linq to Entitiesvs. EntitySQL 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 32 98 44 EntitySQL 42 109 4 2 Linq to Entities (compiled ) 137 Advanced (lazy) 82 48 Linq to Entities Advanced (optimal) Simple Data Access
  • 15.
    Lazy vs. eagerloading Eager loading is resource-consuming Lazy loading is time-consuming L2S has implicit lazy loading built-in EF has explicit lazy loading built-in It is always a dilemma… Get what you really need! 85 102 L2S 63 97 L2S (compiled) 32 98 EntitySQL 42 109 Linq to Entities (compiled ) 137 Advanced (lazy) 82 Linq to Entities Advanced (eager) Data Access
  • 16.
    Data modification L2Sand EF contexts are Units of Work: get => change => save all Only when tracked 2,952 156 52 EF 12,075 268 153 L2S 75 Advanced 2,285 42 Commands Heavy Simple Data Modification
  • 17.
    SQL generation Getyour SQL profilers ready! 33% 33% 33% Simple retrieval N/A N/A N/A Advanced retrieval (lazy) 24% 55% 21% Advanced retrieval (optimal) N/A N/A 33% EF N/A N/A 33% L2S N/A Advanced modification N/A 33% Readers/ Commands Heavy modification Simple modification Queries
  • 18.
    Performance advices choosethe 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
  • 19.
  • 20.
    Useful links http://msdn.microsoft.com/en-us/library/cc853327.aspxhttp://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