Question

我有一个长时间运行的进程，它集成了一组传入的实体，以确定传入实体是否与持久存储中的实体不同。

当我第一次写这篇文章时，我从数据库中检索了与我正在比较的实体相匹配的每个实体，我也有一些包含来引入我需要比较的引用实体。这非常慢，因为每次比较都涉及数据库查询，然后是实体框架'修复'。

我现在正在使用查询来引入我比较所需的所有实体，然后再开始这个过程。这让我可以提前获得速度，这样我就可以大大加快我的进程速度。但是，初始查询仍需要至少一两分钟才能执行。

Dictionary<long, SomeEntity> someEntities = new SomeEntitiesInclude().ApplyTo(context.SomeEntities)
                                                        .Where(se => se.SomeRelatedEntity.ID == relatedEntityID)
                                                        .Where(se => se.SCDCurrent == true)
                                                        .OrderBy<SomeEntity, long>(se => se.SomeRelatedEntity.ID)
                                                        .ToDictionary<SomeEntity, long>(se => se.SomeRelatedEntity.ID);

由此产生的实际sql查询只需要几秒钟的时间来执行，所以我认为大部分时间都花在“修复”上，因此上下文可以跟踪更改。

SomeEntitiesInclude对象允许我使用强类型包含语句，并且是由Alex James开发的IncludeStratergy类的子类：http://blogs.msdn.com/alexj/archive/2009/07/25/tip-28-how-to-implement-include-strategies.aspx

是否有人提示加快执行此操作？

为长期问题道歉。

詹姆斯

Answer 1

有很多事情可能会减慢这种速度。修复其中一个。通过投影到非实体类型，很容易测试修复是否是问题。这完全取消了对等式的修正。如果这解决了问题，那么它可能会解决问题，我们可以从中解决问题。

另一方面，它可能无法解决问题，因为还有其他因素可能会减慢查询的执行速度。我要看的第一件事是从LINQ表达式到SQL的查询编译。您可以使用CompiledQuery类型来隔离此步骤。如果生成CompiledQuery需要很长时间，但执行生成的方法只需要很少的时间，那么就找到了性能问题的根源。

然而，在执行任何此操作之前，我可能会确保您的查询不会不必要地复杂化。不知道你在做什么，确切地说，我不能说你是否真的需要你回来的所有领域。但是如果你只需要几种类型的几个字段，你最好投射到一个非实体类型，而不是返回完全物化的实体。

在内存中保存Entity Framework对象图的最佳方法是什么？

1 个答案: