Sneak Preview: Entity Framework 5.0 Performance Improvements
An O/RM, like any layer of abstraction, introduces overhead to data access. In EF 5.0 we have taken steps to reduce this overhead and improve performance. As a result in one of our tests, repeat execution time of the same LINQ query has been reduced by around 6x. We also have an end-to-end application that we use for performance testing that is running 67% faster.
LINQ to Entities Query Repeat Execution Time
In EF 5.0 we are introducing automatic compilation of LINQ to Entities queries. From the first version of EF, developers have been able to compile LINQ queries explicitly by calling CompiledQuery.Compile, but many developers either were not aware of this ability or found the API harder to work with than regular LINQ. In EF 5.0 we took on some of this work for you, so that the translation of inline LINQ queries is now cached without having to use CompiledQuery. This improvement, together with an optimization in how we evaluate query parameter values, has had a profound impact on the query performance of EF:
The graph above represents the relative time spent in the execution of a query that retrieves an entity by its key. The same logical query was executed via ADO.NET, LINQ to SQL and several EF methodologies. In the benchmark, the query is executed in a loop using different key values each time. From the graph above we can see that before these performance improvements, executing a LINQ to Entities query for the second time took 23.14 times as long as the same SQL query using classic ADO.NET. With automatic query compilation and the changes to parameter evaluation, we’ve improved the performance of LINQ to Entities queries nearly 600% when compared against EF 4.0. As a bonus, EF 4.0 applications will get this performance improvement for free by just upgrading to .NET 4.5.
End-to-End Performance
It would be amazing if we could give you 600% improved performance across the board. Unfortunately, most applications do more interesting things than run the same query repeatedly. Internally we have a suite of performance tests that run a variety of operations designed to simulate the typical usage a real-world application would have. We set thresholds based on the performance of EF 4.0 to ensure that we do not regress performance. These test runs are showing a 67% performance increase over EF 4.0 since we upgraded the server to EF 5.0:
We Aren’t Done Yet!
This means that many real-world applications will automatically show substantially improved performance when they start using EF 5.0. Naturally, how much faster a specific application will become will depend on many variables that would be impossible to predict in a benchmark.
We aren’t done improving performance yet, but we’re excited about how much faster EF 5.0 is. These numbers are based on an internal build, but we’re working hard to get a build available for public verification of these improvements.
As always, your feedback is important to us. Feel free to leave comments or concerns below.
Thanks,
The Entity Framework Team
Comments
Anonymous
February 14, 2012
Excellent! My open source app Gallery Server Pro offers the choice of two data providers - SQL Server using stored procs and ADO.NET, and SQL CE using EF/code first. The latter approach is dramatically slower than the first, often being unusable for many users. I am not sure how much of the difference lies with the SQL CE engine or with EF, but I welcome these perf improvements.Anonymous
February 14, 2012
It looks like awesome improvements! But it also raises other questions. For example how is performance of the first run affected or how are compiled queries cached? Is there some MRU cache or unlimited cache? What will happen in case of occasionally run queries?Anonymous
February 14, 2012
The comment has been removedAnonymous
February 14, 2012
Did you fix the performance issue with the Contains() operator as documented here: stackoverflow.com/.../why-does-the-contains-operator-degrade-entity-frameworks-performance-so-dramaAnonymous
February 14, 2012
@David: Thanks for very clear explanation. This make the new feature even more interesting.Anonymous
February 14, 2012
@Mike: No, EF 5 doesn't include an improvement for Contains. A workaround like the one I described in SO (i.e. partitioning the in-memory collection into chunks) is still the best workaround I know when you have a large number of items. We will have to prioritize this for the next release. I encourage you to check http://ef.mswish.net to see if the feature request is there and otherwise add it.Anonymous
February 14, 2012
So if we're already using CompiledQuery.Compile in EF 4, can we expect to see any performance changes?Anonymous
February 14, 2012
Does it include code first?Anonymous
February 14, 2012
@Bob: EF 5.0 is DbContext API on top of .NET 4.5, so yes it also includes code-first.Anonymous
February 14, 2012
hi, is the performance issue for TPT inheritance fixed in ef 5 ?Anonymous
February 14, 2012
forget my question, i just noticed on mswish.net that you started the dev :)Anonymous
February 14, 2012
@Joel: No, in general there is no significative improvement for CompiledQuery per se in EF 5.0. Depending on the query you might see some benefit if we were generating SQL that is more efficient.Anonymous
February 14, 2012
Is there any plan to add async support?Anonymous
February 14, 2012
@async, Async support is still on the backlog but we definitely plan to tackle it soon.Anonymous
February 14, 2012
@async: Yes, we have been looking at adding async support and have been working with other teams at Microsoft so that all the necessary building blocks are in place. It is not coming in EF 5.0 but in a later release, so you will have to await for it :-). I encourage you to vote for the feature here: data.uservoice.com/.../1015385-support-for-asynchronous-queries.Anonymous
February 14, 2012
Is there support for Compiled Queries through the DbContext interface?Anonymous
February 14, 2012
I take my question back. This works fine: static public Func<ClinicalContext, string, Issuer> QueryIssuerByName = (context, issuerName) => context.Issuers.Where(c => c.Name == issuerName).FirstOrDefault(); The reason why I was confused was that I usually wrap the initialization in a Lazy<T> like the following: static public Lazy<Func<ClinicalContext, string, Issuer>> QueryIssuerByName2 = new Lazy<Func<ClinicalContext, string, Issuer>>(() => CompiledQuery.Compile<ClinicalContext, string, Issuer>((context, issuerName) => context.Issuers.Where(c => c.Name == issuerName).FirstOrDefault()), LazyThreadSafetyMode.PublicationOnly); This used to compile when ClinicalContext inherited from ObjectContext instead of DbContext. Not sure why the compiler no longer likes this. Error 1 The type 'ClinicalContext' cannot be used as type parameter 'TArg0' in the generic type or method 'System.Data.Objects.CompiledQuery.Compile<TArg0,TArg1,TResult>(System.Linq.Expressions.Expression<System.Func<TArg0,TArg1,TResult>>)'. There is no implicit reference conversion from 'ClinicalContext' to 'System.Data.Objects.ObjectContext'. Note the mention of ObjectContext, which cause my confusion.Anonymous
February 14, 2012
Any performance improvements for instantiating a context several with houndreds of entities? This is the biggest pain point for EF right now for us, even when using precompiled views. The first time instantiation of the context takes about 20 seconds (3 minutes without precompiled views). Any performance improvements in this area?Anonymous
February 14, 2012
How are queries with variable sorting, grouping, etc affected? This is a common scenario when exposing IQueryable through domain service, example: a client clicking the column headers of a Silverlight RIA bound grid to change sorting. Does the optimization in how you evaluate query parameters consider sort order as a parameter?Anonymous
February 14, 2012
Good work! Is performance of more complex queries and TPT queries also improved such that it can compete with (or better outperforms) the query times reported in the CodeProject article "Improving Entity Framework Query Performance Using Graph-Based Querying" at www.codeproject.com/.../Improving-Entity-Framework-Query-Performance-UsingAnonymous
February 14, 2012
@Fadi: I am not super familiar with how RIA builds these queries but I imagine it builds different expressions different for each variation rather than using parameters, since this is the simplest option and should produce simpler queries. If that is the case then each variation, e.g. ascending vs. descending order will get a distinct entry in the cache. The parameter evaluation optimization the post mentions consists on switching to reflection in many cases in which doing so is much more efficient that compiling expression trees into delegates and invoking them dynamically as we used to do. In particular we now use reflection to access fields in the method's closure, which is the most common way of capturing parameters in LINQ.Anonymous
February 14, 2012
I'm surprised to see that the team left out compiled queries for LINQ to SQL. Is the team unable to beat LINQ to SQLs low 7% overhead compared to a ras SqlDataReader? (don't believe me? google for Microsoft performance guru Rico Mariani's blog posts on the subject).Anonymous
February 14, 2012
Very nice! Even more important than enums. Why did LINQ to SQL improve as well? Has it been optimized, too?Anonymous
February 14, 2012
Please include the benchmarks for the equivalent compiled query in LINQ to SQL. It's still a supported part of the BCL. Unless added, developers might come across this blog post and get the impression that compiled queries aren't supported by LINQ to SQL.Anonymous
February 14, 2012
This cache that you're talking about... Is it in memory, disk?Anonymous
February 14, 2012
Finally - I wish the pre-compiled behaviour was implemented earlier than now! It is very painful and ungainly to use the CompiledQuery.Compile pattern over and over and over in our code. Using Entity SQL we lose the benefit of compile time error checking of the queries. I hope this improvement is pushed to release soon and that I can use it even without having the need to upgrade to .NET Framework 4.5. Would that be possible? @Mike - I just posted an workaround we used very successfully for the "Contains" problem. Please see stackoverflow.com/.../10458 . @Catalin Pop Sever - We have the same problem - we have a large EF model and it takes ages to get instantiated. First time is bad - but the subsequent times are not good either. I wish this problem was addressed soon.Anonymous
February 14, 2012
Hi! One more time you overcome all of our expectations! This is a great new! Congratulations for your work! Good work!Anonymous
February 14, 2012
Is the initial startup time related to this issue on the uservoice site? Or does it need better wording? data.uservoice.com/.../2409974-speed-up-view-generation-process It definitly needs lots of more votes.. I hate running unittests in a lib where some sort of EF is involved, it takes 15 seconds to startup each time.Anonymous
February 14, 2012
The comment has been removedAnonymous
February 14, 2012
How does this performance compare to NHibernate?Anonymous
February 14, 2012
The comment has been removedAnonymous
February 14, 2012
btw; that tool crashes on first attempt (and yes, XEntities is in the correct place, the designer etc works) System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidOperationException: No connection string named 'XEntities' could be found in the application config file. at System.Data.Entity.Internal.LazyInternalConnection.get_ConnectionHasModel() at System.Data.Entity.Internal.LazyInternalContext.InitializeContext() at System.Data.Entity.Internal.InternalContext.ForceOSpaceLoadingForKnownEntityTypes() at System.Data.Entity.DbContext.System.Data.Entity.Infrastructure.IObjectContextAdapter.get_ObjectContext() --- End of inner exception stack trace --- at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeType typeOwner) at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams) at CallSite.Target(Closure , CallSite , Object , String , BindingFlags , Object , Object , Object ) at System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) at Microsoft.DbContextPackage.DbContextPackage.GetObjectContext(Object context) at System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1) at Microsoft.DbContextPackage.DbContextPackage.OptimizeContext(Object context)Anonymous
February 14, 2012
Any details on batch update/delete?Anonymous
February 15, 2012
Would EF 5.0 be compatibility with .NET 4.0?Anonymous
February 15, 2012
@Ladislav Mrnka you intend to update EF Power Tools? Generated views doesn´t work with SQL CEAnonymous
February 15, 2012
@Anders Borum: Thanks for bringing this up. In this particular benchmark the LINQ to SQL version of CompiledQuery gets a score of 2.41. Only slightly faster than the LINQ to Entities.Anonymous
February 15, 2012
The comment has been removedAnonymous
February 15, 2012
Can you provide a benchmark between NHibernate and EF 5.0. Thank you.Anonymous
February 15, 2012
Why is there a little performance drop for Raw Sql and Compiled Queries in .Net 4.5 ?Anonymous
February 15, 2012
What's new in EF 5.0 other than performance improvements?Anonymous
February 16, 2012
The comment has been removedAnonymous
February 17, 2012
It looks like you're adding to the performance improvements from the June 2011 CTP. It's a pity that you pulled these features back to .NET 4.5, especially in light of the widely-held suspicion that 4.5 won't support any flavor of XP. While I know this article is specifically about performance, what about the tools? Even if we can't go live with the various runtime improvements in the June CTP, can the designer tools be used by themselves with any of the existing versions of EF (4, 4.1, 4.2, 4.3)?Anonymous
February 19, 2012
Will enums be available as a part of a primary key in EF 5?Anonymous
February 19, 2012
@Viktar: Yes, enums can participate in entity keys in EF 5.Anonymous
February 19, 2012
@Adam Robinson: The June 2011 CTP only included auto-compiled LINQ queries. The upcoming .NET 4.5 beta will include further changes. Each version of Entity Designer usually works with previous versions of the EF. You should should be able to specify the right target .NET framework for your app and the designer should still work.Anonymous
February 19, 2012
What is the probability that FW 4.5/EF5 is out by the middle of summer?Anonymous
February 20, 2012
Any improvements in View Generation time for models with large number of entities?Anonymous
February 21, 2012
Here's my ultimate wish: "EF Lite"! Keep the LINQ bits, but run them against POCOs without any runtime modifications. Object instantiation should be as fast as what we would get with regular classes. Of course it would not have state tracking and other fancy features, but it would be super fast (as close to ADO.NET as possible). I'd be more than happy to give up on these features if I could still have the compiler check the queries. Do this and you'll see a ton of performance-conscious sites (usually big ones or in start-ups) bring you a lot of positive PR -- see why SO had to let go of LINQ to SQL. It's all about performance, performance, performance...Anonymous
February 22, 2012
Hi, Do you use complied queries (aka prepared sql statements) in SQL (Server) as well?Anonymous
February 23, 2012
EF Team, Thank you for listening to the development community, communicating with us, and delivering excellent work time and time again. I am wowed! Sean StenlundAnonymous
February 23, 2012
@Anil Mujagic: We found and fixed an issue in our code that was triggering View Generation to happen more than once per model and AppDomain. The fix could result in a significant improvement for the cases in which you are not using pre-generated views and the views are generated at runtime. View Generation per se still has the same level of complexity as before, therefore if you are using pre-generated views I wouldn't expect a significant improvement in EF 5.0.Anonymous
February 26, 2012
First up excellent work! Looking forward to installing EF 5.0 One point I like to ask is this - Over on http://ef.mswish.net you state: "EF 5.0 contains significant improvements for TPT, but there are futher improvements we would like to make in the long run." Have you done any benchmarking on this? Does your comment just relate to the automatic caching of the queries or have you made fundemental changes to the way that TPT queries are generated. Andy NewlandAnonymous
February 27, 2012
We currently have an issue using contains with the following structure: context.ChildD .Where(cd => someListofIDs.Contains(cd.ChildC.ChildB.ChildA.ID)) ... query continues. In this state we get a long query compile time with a left outer join created FOR EACH id in the list. The current workaround is to do something similar like this: context.ChildD .Select(cd => new { CD = cd, IdWeNeed = cd.ChildC.ChildB.ChildA.ID }) .Where(anon => someListofIDs.Contains(anon.IdWeNeed)) .Select(anon => anon.CD) ... query continues. Is this behavior still exhibited in 5.0 and if so can we get this fixed? Are table value parameters supported in 5.0 and if so are they compilable?Anonymous
February 27, 2012
I'd like to hook up to Catalin Pop Sever's question from Feb 14. To me startup performance when instantiating the 1st context one of the major issues. We have an entity model comprising roughöy 250 entities. Even with precompiled views the 1st instantiation of a context takes more than 30 secs. This is really annoying to our users. Any improvement in EF 5 or at least on the agenda in this area?Anonymous
February 29, 2012
The comment has been removedAnonymous
March 01, 2012
Using the VS Template it should create code according to the unit of work patternAnonymous
March 01, 2012
I am just thinking is this possible that when EF run a query first time, it translate that query into a stored procedure and store it to DB, and later then EF will call that SP instead of run that query.Anonymous
March 01, 2012
Still no Pluggable Conventions? What's happening here, my OnModelCreating is running to nearly 1000 lines of code.Anonymous
March 02, 2012
I'm trying to understand something in the graph. You have a comparison showing "EF Compiled Query" vs "EF Linq to Entities". Is this comparing the performance of using System.Data.Objects.CompiledQuery.Compile vs using automatically compiled queries? If so, (1) why is CompiledQuery.Compile so much faster? (2) will CompiledQuery.Compile be supported with the DbContext? Especially for those of us that have already made the effort to use them in existing code.Anonymous
March 07, 2012
Does EF 5.0 contain any parameterization improvements to use more SQL parameters so SQL Server can use the proc cache more efficiently? stackoverflow.com/.../force-entity-framework-to-use-sql-parameterization-for-better-sql-proc-cache-reuAnonymous
March 10, 2012
@Gordon: we haven't introduced that kind of changes in parameterization. Still the rule of thumb is that constants inlined in LINQ queries a translated to constants and variables are translated to parameters. There is an issue with the parameterization of Skip and Take because of how Skip and Take are designed. I will follow in the StackOverflow thread.Anonymous
March 10, 2012
@Reis: In the chart "EF Compiled Query" does indeed represent CompiledQuery and "EF Linq to Entities" refers to inline LINQ queries. CompiledQuery was introduced precisely as an alternative way of defining queries that allows users to achieve better performance, although it sacrifices legibility. What the chart is also showing is that a big difference in performance between compiled queries and non-compiled queries that existed in .NET 4.0 (the blue columns) has been dramatically reduced in .NET 4.5 (the red columns) with the introduction of auto-compiled queries. Although there is overhead in auto-compiled queries (e.g. we need to perform the first phase of the translation in order to compute the cache key) it is small. Keep in mind that in a typical application there is a mix of different types of queries, i.e. not all of the queries will return a single entity based on its key, some will materialize larger objects and full graphs. In all those cases the relative cost of query translation thins compared with other parts of query processing. We are not planning to add support for CompiledQuery in DbContext queries in EF 5.0, but I encourage you to test auto-compiled query to see what the actual performance impact is for your application.Anonymous
March 11, 2012
could you please look in this, stackoverflow.com/.../ef-5-beta-with-vs-2011 After removing WCF DS CTP and EF June CTP I can no longer add edmx file in neither VS 2011 nor 2010 they look fro System.Data.Entity.dll 4.2.0.0Anonymous
March 18, 2012
@PGMaps2012: we have heard reports that uninstalling the EF June CTP (at least sometimes) leaves behind a publisher policy that contains assembly redirection directives that point to version of System.Data.Entity.dll included in the June CTP. You should be able to remove the publisher policy as you would do with any application in the Add/Remove control panel.Anonymous
March 23, 2012
目前，世界上95%以上的.Net应用，都是在XP系统上的应用。.Net4.5不支持，等于放弃95%的市场。微软，你不要再做这事了.Anonymous
March 27, 2012
I've done quite a bit of performance testing with EF5 and found some pretty cool performance benefits, from what I can see its a lot faster so long as the number of attached items is relevantly small and as the number of items in the context increases it converges on the same performance as EF4. (see blog.staticvoid.co.nz/.../entity-framework-comparative.html ) My tests are all fairly simple so I don't think I'm getting any real benefit from compiled queries (no big differences from EF4 anyway). If anyone has any suggestions on some better tests to bring out when compiled queries are a real benefit i would love to hear them.Anonymous
March 28, 2012
@Luke McGregor: Your benchmark results look very interesting. I am curious about one detail: you mention you used .NET 4.5 to run all your tests, however, most of the performance improvements between EF 4.1 and EF 5.0 are implemented in .NET 4.5. Any chance you actually run the EF 4.1 tests on .NET 4.0 and the EF 5.0 tests on .NET 4.5 and then you forgot to mention it? Also, I haven't looked at the code of your benchmarks, but there are some general rules of thumb that could explain the convergence you are seeing:
- As you increase the amount of data returned by a single query, the relative cost of compiling the query diminishes compared with the cost of materialization each object and the cost of transferring the actual data from the server.
- EF currently only supports individual key-based deletes so you need to load all the entities you want to delete in memory, mark them as deleted and the invoke SaveChanges for all the individual DELETE statements to be sent to the database, which is not as efficient as performing deletes directly based on key or sets. I agree with you that if your mapping is trivial, it is perfectly fine to combine tools for a case like this. You could also choose to implement the deletes on the server in a stored procedure that you can easily invoke from context.Database.ExecuteSqlCommand.
Anonymous
March 28, 2012
The comment has been removedAnonymous
April 12, 2012
I think that the improvement must be quite faster than the dapper ORM code.google.com/.../dapper-dot-net then the EntityFramework comes to be the only solution for mapping data. Huge jobs, Excellent, But do more please. thanksAnonymous
April 12, 2012
Thanks EF team. One request for EF 5. We absolutely need better GUID as a primary key support. If we define our primary key as: PersonID uniqueidentifier Default (NEWSEQUENTIALID()) this should be picked up by EF 5 automatically and StoreGeneratedPattern="Identity" should be applied.....and if I "update the model from database" this attribute should not be lost! right now in EF 4.3 we are still having to maintain our xml manually. this is less than ideal. thanksAnonymous
April 13, 2012
@Peter: You pretty much described BLToolkitAnonymous
April 15, 2012
@Naoufal EF and Dapper.NET differ in their feature set, so performance differences will always exist. We are continually working on performance improvements to make EF a better tool for wider audiences. @Justin Thank you for your feedback. The team will look into this. Remember you can always post new requests or vote for existing ones at ef.mswish.net. This helps us drive our priorities. David.Anonymous
April 15, 2012
We are currently using EF 4.1 and the objectcontext. Do we need to switch to using the DBContextApi in order to get the performance improvements for the precompiled linq queries etc?Anonymous
April 15, 2012
@Steve: No, existing applications using the ObjectContext API can take advantage of these performance improvements by simply upgrading from .NET 4.0 to .NET 4.5. DbContext is the recommended API for new applications and it has other advantages like the ease, simplicity and requiring less code to perform common tasks.Anonymous
April 18, 2012
Good Job Microsoft, but in few cases we saw that .net 4.5 is taking more time as compared to .net 4.0 in above first diagram. I hope before final release u will improve it. please provide some more sample applications for beginners to learn.Anonymous
May 08, 2012
In the graph, what do you mean by "EF (Raw SQL)" - Does this mean calling stored procedures from EF?Anonymous
May 09, 2012
Hi EK. By "EF (Raw SQL)" we mean using SQL directly from EF. There are two ways to use SQL code directly from EF:
- ExecuteStoreQuery: this is typically used when using ObjectContext.
- SqlQuery: this is used when using DbContext. Examples: SqlQuery on Database: // use this to obtain entities and not track them var q1 = context.Database.SqlQuery<Product>("select * from products"); SqlQuery on DbSet: // use this to obtain entities and have them tracked var q2 = context.Products.SqlQuery("select * from products"); ExecuteStoreQuery: ObjectResult<Product> beverages = context.ExecuteStoreQuery<Product>( @" SELECT P.ProductID, P.ProductName, P.SupplierID, P.CategoryID, P.QuantityPerUnit, P.UnitPrice, P.UnitsInStock, P.UnitsOnOrder, P.ReorderLevel, P.Discontinued, P.DiscontinuedDate FROM Products AS P INNER JOIN Categories AS C ON P.CategoryID = C.CategoryID WHERE (C.CategoryName = 'Beverages')" ); We highly recommend to use Linq queries instead of raw SQL as it decouples your implementation from the backend. Yet another alternative is using ESQL which has certain advantages seen in SQL but works independently from the backend you use. Let me know if you have additional questions.
Anonymous
May 09, 2012
It is very kind of you to provide this detailed information. Thank you very much.Anonymous
May 18, 2012
ExcellentAnonymous
June 07, 2012
In version 4.* support for Include() in compiled queries seems to be lacking, e.g. will this be solved?Anonymous
June 08, 2012
@Deve Loper - Automatic caching of queries does happen for queries that use Include. If you were still manually compiling queries then the use of Include is still not supported.Anonymous
July 04, 2012
Any samples about using EF5 in MVC? thanksAnonymous
July 05, 2012
@Trung Tran Le Thanh - There will be a set of detailed documentation and walkthroughs coming out when EF5 and Visual Studio 2012 RTM. In the meantime here is an MVC4 tutorial that includes using EF5, I’ve linked to the chapter that uses EF - www.asp.net/.../accessing-your-model&. This video also demos the two together - channel9.msdn.com/.../Rowan-Miller-Demonstrates-Entity-Framework-5-Using-ASPNET-MVC-4.Anonymous
July 08, 2012
Nice tutorial on EF analysis ..... webdesignpluscode.blogspot.comAnonymous
July 19, 2012
Could you add compiled LINQ to SQL to the comparison chart? It'd be interesting to see how it compares to "EF (Compiled Query)". Thanks.Anonymous
July 19, 2012
@Chris Cavanagh: The LINQ to SQL CompiledQuery result is in one of my previous comments: In this particular benchmark the LINQ to SQL version of CompiledQuery gets a score of 2.41. Only slightly faster than the LINQ to Entities.Anonymous
August 09, 2012
I have following perf test results: ADO.NET: 1 Linq to Sql: 7.45 Linq to Sql Compiled: 1.54 EF 5.0 Prerelease: 3.28 I selected single entity (using Single method) by Int64 entity key in cycle with 1K iterations. I started timer before cycle and stopped it after cycle. Before starting timer I maked 1 call of this query to warm up. It seems that EF is significally slower than L2S compiled.Anonymous
August 16, 2012
The comment has been removedAnonymous
September 12, 2012
I recently developed a simple ASP.NET backend for a database using EF 4. It was very easy to access the database content and update them. The performance was ok, but with the new version it would be even better. Good work!Anonymous
September 23, 2012
I had just migrated to EF5.0 but still continued using the ComponentModel.DataAnnotations dll in my domain classes and was having this problem of assembly or using directive missing but Thanks to U guys am good 2 go after landing on the correction in this blog. YOU ROCK!!!!Anonymous
September 25, 2012
@Lukyamuzi Shaban - Glad it was helpful!Anonymous
October 24, 2012
The comment has been removedAnonymous
December 16, 2012
A step in the right direction, but you should really have NHibernate in your graphs. No point keeping your heads in the sand over the still-superior competition.Anonymous
February 23, 2013
Could you explain bit more about graph 2 (End-to-End Performance) ? It is quite difficult to understand the 67% performance increase by using that graph.Anonymous
February 23, 2013
@sampath: Thanks for bringing this up. The graph we originally published only contained data for one of the improvements we made. I have updated the post with a graph I prepared some time ago for a presentation and that contains a more complete part of the data series.Anonymous
April 06, 2014
Hello, Thanks! Can you please share the test code for those comparisons?Anonymous
April 07, 2014
@Michael Sync - We didn't make the source code for these tests public but we are looking at making more of the tests we write in the future open source (including perf tests).