DbContext ChangeTracking杀死性能？

我正在将应用程序从EF1升级到EF4.1 我使用“ADO.NET DbContext Generator”模板创建了一个DbContext和一组POCO。DbContext ChangeTracking杀死性能？

当我查询生成的DbContext时，查询的数据库部分需要4ms才能执行（使用EF Profiler进行验证）。然后在将结果返回给应用程序之前，需要大约40秒的时间（用词：FORTY！）来完成它所做的任何事情。

EF1在少于2秒内处理相同的查询。

关闭AutoDetectChanges，LazyLoading和ProxyGeneration赢得我2-3秒。

当我使用AsNoTracking（）扩展方法时，我能够将总执行时间减少到大约3秒。

这表明ChangeTracking是罪魁祸首。

但ChangeTracking是我所需要的。我必须能够最终坚持所有的改变，而不必亲自挑选哪些实体被修改。

任何想法如何解决性能问题？

来源

2011-05-12 Sebastian Weber

在这里讨论了几次。它看起来像EFv4.1中的一个错误 – 2011-05-12 07:46:35

当我使用EF4.0和“ADO.NET POCO实体生成器”模板时，情况更糟糕。然后它需要超过80秒，直到我有一些结果。所以这个错误在以前的版本中变得更加严重，MS无法在EF4.1中正确地修复它？ – 2011-05-12 08:05:30

您可以尝试关闭'AutoDetectChanges' /使用'AsNoTracking'，但同时创建跟踪代理（所有属性都必须是虚拟的）。我想知道这个曲目是否会改变，现在我无法对它进行测试。 – 2011-05-12 08:12:59

该documentation末尾的技术是否有用？另外，我避免了许多使用流畅接口来声明性地声明给定事务中的哪些实体肯定不会改变而可能改变（不可变或不可改变）的许多性能缺陷。例如，如果我保存的实体是根或其实体引用“refdata”项的聚合根，那么这种启发式防止许多写入，因为不需要跟踪不可变项。这些可变项目都会在没有检查的情况下被写入（一个弱点......一个可能或者可能不被接受）。

我正在使用这与一个通用的存储库模式，因为我不想跟踪更改或实现每个案件的特定策略。如果这还不够，可能会在上下文之外滚动自己的更改跟踪，并根据需要添加实体。

来源

2011-09-09 01:21:22 Kit

链接已损坏 – 2012-11-13 19:09:27

没有看到查询，我不能肯定地说问题可能是什么。这可能是相关的吗？

Why does the Contains() operator degrade Entity Framework's performance so dramatically?

根据正在使用的LINQ运营商，看来EF有一个艰难的时间把一些查询SQL。也许你在这里遇到类似的情况。

来源

2011-11-09 18:33:08 Mike

DbContext ChangeTracking杀死性能？

回答

相关问题