為什麼 DbContext.SaveChanges 在調試模式下慢 10 倍
有人可以解釋
- 為什麼 DbContext.SaveChanges 在調試模式下的執行速度比生產模式慢 10 倍？
- 有什麼辦法可以加快速度嗎？
在調試模式下，我的網頁載入需要 116 秒，而如果我在不調試的情況下啟動項目則需要 15 秒。
我已經設置了跟踪語句，並確定在調試模式下，我的 DbContext.SaveChanges 方法花費了 116 秒中的約 100 秒。
在同一部分中僅花費 7 秒的時間在不調試的情況下執行項目。
如果您想了解更多資訊，請在評論中告訴我。
項目設置：
- ASP.NET 網頁
- VS2012
- SQLServer2012
- 實體框架 5.0
附加資訊：（如果您需要更多資訊，請在評論中告訴我）
- SaveChanges方法累計sql查詢次數為20000
- 生產連接字元串：數據源=PC-DEV；初始目錄=aspnet-2013-06-04；集成安全=True；MultipleActiveResultSets=True；應用程序名稱=EntityFrameworkMUE
- 調試連接字元串：數據源=PC-DEV；初始目錄=aspnet-2013-06-04；集成安全=True；MultipleActiveResultSets=True；應用程序名稱=EntityFrameworkMUE
- 我也經歷過與 LocalDB 作為備份數據庫相同的相對性能
更新：
正如@ruionwriting 所建議的那樣，我對數據庫進行了分析，我發現無論項目是在調試模式下執行還是在生產模式下執行，大約 20,000 個 sql 命令所花費的時間完全相同。（每個命令 0 毫秒）。
但是，在調試模式下，20,000 條命令之間的平均絕對時間差為 5 毫秒。
與生產模式相比，這組命令的平均時間差為 0.3 毫秒。
這是大約 10 倍的時間性能差異，並將實體框架隔離為在調試模式下花費額外時間的原因。
有沒有辦法配置調試建構，以便可以在沒有調試標誌的情況下引用 EntityFramework？
如果我通過某種編譯器魔法以某種方式恢復性能，那麼在調試能力方面我會失去什麼？目前我無法進入實體框架程式碼，所以我認為我不會錯過任何東西。
謝謝！
哇！
好的，所以調試模式異常緩慢的原因是因為 Visual Studio 的 Intellitrace 正在記錄實體框架生成的每個 ADO.NET 事件（全部 20、000 個）。
所以工具-> 選項-> IntelliTrace 並**取消選中“啟用 IntelliTrace”**解決了這個問題。
或者也可以通過轉到 Tools->Options -> IntelliTrace -> IntelliTrace Events 並取消選中 ADO.NET 來過濾掉 ADO.NET 事件
感謝大家的建議。
這裡有一節討論Intellitrace 會減慢我的應用程序的速度