共用方式為

EF6 Performance Issues

  • 發行項

 

When will a fix be available?

We are working to put together a 6.0.2 patch release that addresses the performance issues and some other high priority bugs. We are working to make this patch available quickly, but we also want to make sure we capture as many issues as possible and perform adequate testing to ensure we don’t introduce new issues. While we don’t have definite plans for a release date yet, we’re aiming to make it available in November.

You can view the issues being tracked for inclusion in this patch on our CodePlex site. Note that some issues are still being investigated and won’t show up in the 6.0.2 release until we have identified the root cause.

 

Why did you miss this stuff?

Unfortunately it is not practical  - or even possible - to cover every scenario in our suite of performance tests. Some of these issues have exposed holes in our test suite that we are working to fill. Other issues only manifest when certain model sizes/shapes/patterns are present and they just happen to be areas that are not covered by our test suite.

We realize that reliable performance is important to you, your business, and your customers and we don’t take this situation lightly. In addition to rounding out our performance test suite we will also be reviewing the issues identified in EF6 to understand how we can avoid such issues in the future.

 

The already released 6.0.1 patch release

The 6.0.0 version of the EF package needed to be locked down early to be included in Visual Studio, ASP.NET, etc. After this lock down we identified some other performance issues that we felt needed to be addressed ASAP.

At the same time we released 6.0.0 we also published a 6.0.1 patch release that addressed these issues. If you install from NuGet you will automatically get the latest patch version. If you use a VS2013 project template that already has EF6 installed, or if the EF6 tooling installs the NuGet package for you, we would recommend updating to the latest patch version. You can do this by running Update-Package EntityFramework in Package Manager Console.

You can see a complete list of the individual fixes in this patch on our CodePlex site.

 

Improving startup performance with Ngen

Prior to EF6, a large portion of Entity Framework was included in the .NET Framework. This meant that most of Entity Framework automatically has native image generation run on it to reduce the just-in-time (JIT) compilation cost.

Because EF6 ships as a completely out-of-band release, native image generation is no longer performed automatically. This can result in an increased warm-up time for your application while JIT compilation occurs – we have seen results of around 1 second.

To remove this JIT time you can use Ngen to generate native images for the Entity Framework assembly on your machine. For more information, see Improving Startup Performance with NGen.

Comments

  • Anonymous
    October 31, 2013
    The comment has been removed

  • Anonymous
    October 31, 2013
    Maybe, you'll just implement the second-level caching support. How long will be just a proposed task on uservoice? data.uservoice.com/.../1015353-second-level-cache

  • Anonymous
    November 01, 2013
    The comment has been removed

  • Anonymous
    November 04, 2013
    @Joel - F# hasn't been something we have really tried to support with Migrations thus far. That said, we have just recently seen a number of folks asking us to make it work. It won't be in 6.0.2, but we are going to take a look at unblocking F#. The amount of work involved will determine when/how we ship it.

  • Anonymous
    November 04, 2013
    @Andrei/Jon - 2nd level cache is near the top of our backlog in terms of votes etc. (along with a number of other features). Unfortunately we can't implement everything immediately so we have to pick and choose what we implement based on feedback/votes and a number of other factors. We're still in the planning stage for the next set of releases at the moment.

  • Anonymous
    November 04, 2013
    @Jon - We try to make anything we implement these days as pluggable as possible, so you can remove/replace if the behavior doesn't work for you. We would definitely take this approach with any caching we added.

  • Anonymous
    November 04, 2013
    Thanks to the team for keeping us in the loop. With code first and code migration, EF is now my favourite .Net ORM. It would be a shame if performance was the show stopper...

  • Anonymous
    November 04, 2013
    An Data api with poor performance just like a Flashlight with low battery. The features of EF are enough, i really dont need more, but please please improve the performance. people have been waiting so long time. Wish ef performance can reach the level of L2S, or even close to ado.net.

  • Anonymous
    November 05, 2013
    @Rowan - it's not just that EF doesn't work with F# if you're using migrations. It simply won't install on an F# project. See entityframework.codeplex.com/.../891 and stackoverflow.com/.../getting-ef-6-from-nuget-to-install-on-f-projects. If MS is serious about F# - by no means a given - I would have assumed that that would be a show-stopper.

  • Anonymous
    November 06, 2013
    @Ken Smith - Got it. Up until now F# hasn't been a scenario we have worked on or tested for EF. I'm not saying that's how it should have been, but we hadn't really heard of folks using EF with F# so it just wasn't a priority for us. However, in the last month or so we've heard from a number of folks who do want to use EF with F#. We're going to dig into the issues now, but I don't know that anything will make it into 6.0.2 due to the very tight timeline on that patch.

  • Anonymous
    November 11, 2013
    Hey! There are really many folks who use f# and EntityFramework.

  • Anonymous
    November 12, 2013
    These performance issues are critical (probably should have prevented EF6 from reaching graduating from Beta/RC). My boss is pressuring us to rollback to EF5 as a 150 table schema now takes 60-90 seconds for the DbContext to load first time under Code First. At the very least a firm release date for patches would be very helpful.

  • Anonymous
    November 13, 2013
    The comment has been removed

  • Anonymous
    November 19, 2013
    @Ben & @Jon - There are nightly builds of 6.0.2 available now. It would be great if you could try them out and let us know if there are any residual performance issues. blogs.msdn.com/.../6-0-2-nightly-builds-available.aspx We don't have an exact date for the patch (we'll ship it as soon as we've addressed all the issues we are aware of). That said, we have committed to shipping it this month.

  • Anonymous
    November 25, 2013
    Why you test it EF 6.0.1 before release? You cause me to lost lots of time!

  • Anonymous
    November 27, 2013
    @TEST IT - We do run a lot of testing before we do a release, but we do understand the impact it has when we miss things so we are improving our performance test coverage at the moment.

  • Anonymous
    December 11, 2013
    Hi Guys, How is the 6.02 patch going. Are you any closer to having an ETA?

  • Anonymous
    December 13, 2013
    @LP - We just published RTM blogs.msdn.com/.../ef6-0-2-rtm-available.aspx

  • Anonymous
    December 18, 2013
    STILL NO SUPPORT FOR UNIQUE CONSTRAINT DEFINITION??????????

  • Anonymous
    January 16, 2014
    F# is the best thing MS has going for it in the language arena.  But I have to wonder if this is a 1st class Microsoft language or not? It's the only thing that's kept me on VS instead of just ditching the whole MS stack. F# support is extremely important and I can't ask the team I'm on to start using this stuff in a coherent way when these kind of gotchas exist. Please fix.

  • Anonymous
    January 17, 2014
    @Need F# support - If you are referring to this issue that prevents the package from being installed in F# projects - entityframework.codeplex.com/.../891. That is fixed in the 6.1 code base and will ship in the next preview.