与ObjectContext相比，为什么在EF 4.1中插入实体这么慢？

Question 1

基本上，我在一个事务中插入35000个对象：

using(var uow = new MyContext()){
  for(int i = 1; i < 35000; i++) {
     var o = new MyObject()...;
     uow.MySet.Add(o);
  }
  uow.SaveChanges();
}

这需要永远！如果我使用基础ObjectContext（通过使用IObjectAdapter），它仍然很慢，但大约需要20秒。似乎DbSet<>正在执行一些线性搜索，这需要花费大量时间...

还有其他人看到这个问题吗？

Question 2

正如Ladislav在评论中已经指出的那样，您需要禁用自动更改检测以提高性能：

context.Configuration.AutoDetectChangesEnabled = false;

默认情况下，DbContextAPI中启用了此更改检测。

DbContext行为与ObjectContextAPI之所以如此不同的原因是，启用自动更改检测后，与API的函数相比，API的内部DbContext调用更多。DetectChangesObjectContext

在这里，您可以找到DetectChanges默认情况下调用的那些函数的列表。他们是：

的Add，Attach，Find，Local，或Remove成员DbSet
的GetValidationErrors，Entry或SaveChanges成员DbContext
在Entries对方法DbChangeTracker

特别是导致您体验不佳的Add呼叫DetectChanges。

与此形成对比的是，ObjectContextAPIDetectChanges仅自动调用，SaveChanges而不会自动调用，并且不会自动调用AddObject上面提到的其他相应方法。这就是为什么默认性能ObjectContext更快的原因。

他们为什么DbContext在这么多功能中引入了这种默认的自动更改检测功能？我不确定，但似乎认为禁用它并DetectChanges在适当时点手动调用是高级的，并且可以轻松地将细微的错误引入应用程序，因此请谨慎使用[it]。

Question 3

EF 4.3 CodeFirst的小经验测试：

使用AutoDetectChanges = true删除了1000个对象：23秒

使用AutoDetectChanges = false移除了1000个对象：11秒

插入1000个具有AutoDetectChanges = true的对象：21秒

使用AutoDetectChanges = false插入了1000个对象：13秒

Question 4

在.netcore 2.0中，它已移至：

context.ChangeTracker.AutoDetectChangesEnabled = false;

Question 5

除了您在这里找到的答案。重要的是要知道，在数据库级别，要完成的工作要比添加的要多。数据库必须扩展/分配新空间。然后，它必须至少更新主键索引。尽管索引可能在更新时也进行了更新，但它却很少见。如果有任何外键，则还必须读取这些索引，以确保保持引用完整性。触发器也可以发挥作用，尽管它们可以以相同的方式影响更新。

所有这些数据库工作对于由用户条目发起的每日插入活动都是有意义的。但是，如果您只是上载现有数据库，或者具有一个会生成大量插入内容的过程。您可能需要研究将其推迟到最后的方法。通常在插入时禁用索引是一种常见的方法。根据具体情况可以进行非常复杂的优化，这些优化可能会让人有些不知所措。

只需知道，一般来说插入将比更新花费更长的时间。