批量操作後DbContext的速度很慢

看起來好像EntityFramework中的DbContext越來越慢地執行更多的操作（添加，刪除，修改，查詢）。在幾次操作後定期調用SaveChanges（）將無法解決該問題。唯一的解決方法是處理上下文並重新生成它。批量操作後DbContext的速度很慢

向您傳達一個想法：一個使用一個DbContext的過程需要大約4個小時，而解決方法的代碼需要大約45分鐘，所以它非常重要！有沒有原因或轉換我不知道？

來源

2013-02-27 Uli Armbruster

請參閱[爲什麼插入太慢]（http：// stackoverflow。com/questions/5943394/why-is-inserted-entities-in-ef-4-1-so-slow-comparative-to-objectcontext/5943699＃5943699）和[插入最快的方式]（http：// stackoverflow。 com/questions/5940225 /最快插入實體框架/ 5942176＃5942176） – 2013-02-27 01:16:21

感謝Mark，但我需要DetectChanges。如果我週期性地處理和實例化上下文，DetectChanges不會導致性能問題。我只是想知道爲什麼SaveChanges（）沒有解決方案，因爲在這之後它應該和新的上下文具有相同的起始位置？！或者我錯了？在此之後，上下文應僅檢測修改，添加，刪除SaveChanges（）後實體的更改... – 2013-02-27 02:17:36

您是否在使用更改跟蹤代理POCO？ – 2013-02-27 03:57:44

看來，如果在的DbContext中的EntityFramework弟妹慢的多操作（添加，刪除，修改，查詢），你就可以執行。

它絕對會 - 你的DbContext（和它所基於的ObjectContext）保存了它觸及，加載，更新和保存的每個實體。

快速摘自一個MSDN blog post：

您使用的ObjectContext的越多，通常就會越大。這個是因爲它持有一個它所知道的所有實體的引用，基本上是你查詢，添加或附加的。所以你應該重新考慮無限期地共享同一個ObjectContext。

既然你說的過程大概需要4個小時，我假設你有成千上萬的被修改的實體。保存更改不會轉儲對象圖，您只是創建越來越多的跟蹤。每次進行更改時，都必須遍歷圖形，因此圖形越大，所需的時間越長。

是你的解決方法真的很糟糕的代碼？有沒有辦法來分割你的過程，以便每個部分都創建並處理它自己的DbContext而不是共享一個？

來源

2013-02-27 04:33:30

就像你說的那樣：我必須進行批量操作，並且由於身份映射模式，一切都「緩存」。由於EF可以很快地重新創建上下文，所以我可以用這種方式實現它。當然，在每一次操作中使用新的上下文都有一個明智的論點。 – 2013-04-04 11:07:26

這是performance considerations for EF5的有用鏈接。

您使用的是更改跟蹤代理嗎？如果沒有，你可能會加快速度。從鏈接：

當POCO實體沒有變化跟蹤代理，更改通過比較你的實體的內容與一個先前儲存的狀態的副本中找到。如果您的上下文中有許多實體，或者您的實體具有非常大的屬性，即使上次比較發生後沒有任何發生更改，此深度比較也將變爲冗長的過程。

否則，您可以根據評論和鏈接中的建議設置DbContextConfiguration.AutoDetectChangesEnabled = false。在完成一些通常會自動調用它的密集DbSet/DbContext方法調用之後，仍然可以明確地調用DetectChanges()。

您是否還可以減少上下文中的實體數量？也許使用AsNoTracking（）查詢是否有一些實體不需要被ObjectStateManager跟蹤。

來源

2013-02-27 04:24:58

謝謝！這個鏈接很棒。 – 2013-04-04 10:29:51

批量操作後DbContext的速度很慢

回答

相關問題