似乎EntityFramework中的DbContext在您执行的操作（添加，删除，修改，查询）越来越慢。在几次操作后定期调用SaveChanges（）无法解决该问题。唯一的解决方法是处置上下文并重新生成它。
向您传达一个想法：一个使用一个DbContext的过程需要大约4个小时，而带有变通方法的代码只需要大约45分钟，所以它非常重要！有没有我不知道的理由或转变？
答案 0 :(得分：1)
这是performance considerations for EF5的有用链接。
您使用的是更改跟踪代理吗？如果没有，你可以加快速度。从链接：
当POCO实体没有更改跟踪代理时，更改为 通过比较您的实体的内容与a的副本找到 以前保存的州。这种深刻的比较将变得漫长 当您在上下文中有许多实体时，或当您的实体中有多个实体时 实体具有非常大量的属性，即使它们都不是 自上次比较以来发生了变化。
否则，您可以按照评论和链接中的建议设置DbContextConfiguration.AutoDetectChangesEnabled = false。在完成一些通常会自动调用它的强化DbSet / DbContext方法调用之后，您仍然可以显式调用DetectChanges()。
您是否还可以减少上下文中的实体数量？如果你有一些不需要被ObjectStateManager跟踪的实体，也许可以使用AsNoTracking（）查询。
答案 1 :(得分：1)
似乎EntityFramework中的DbContext不断获取 执行越多的操作（添加，删除，修改，查询）越慢 在它上面。
绝对可以 - 您的DbContext（以及它所基于的ObjectContext）保存了它所触及，加载，更新，保存的每个实体。
快速摘自MSDN blog post：
使用ObjectContext的次数越多，通常越大。这个 是因为它拥有它所知道的所有实体的参考 关于，基本上你查询，添加或附加的内容。所以 你应该重新考虑无限期地共享同一个ObjectContext。
由于您说过程大约需要4个小时，我假设您有数千个正在修改的实体。保存更改不会转储对象图，您只是创建越来越多的跟踪对象。每次进行更改时，都必须遍历图形，因此图形越大，所需的时间越长。
你的解决方案是非常糟糕的代码吗？有没有办法分割你的流程，以便每个部分创建，并处理它自己的DbContext而不是共享一个？