ADO.net，Linq to SQL和Entity Framework性能實測分析

ADO.net，Linq to SQL和Entity Framework性能實測分析

　　最近文檔寫了不少，導緻Word和Excel的使用能力飛一般成長。考慮到項目中讀寫資料庫的方法存在效率不高，以緻影響使用者體驗的問題，決定測試一下Microsoft新推行的Linq和EF能不能在效率上有所改進。

　　測試環境當然就是我這台筆記本了，受限與硬碟轉速，運作起來一定是不如桌上型電腦的，但至少保證了三個方案相同的軟硬體環境：Windows Server 2008，Visual Studio 2008，MS SQL Server 2008，清一色的最新産品。

　　測試分成六個階段，資料量分别為10，10，100，1千，1萬，10萬逐級增長，分别測試了讀取、寫入、更改、删除四個基本的操作的耗時，結果如下（時間機關：秒）：

第一次讀寫10條資料

第二次讀寫10條資料

操作100條資料

操作1000條資料

操作10000條資料

操作100000條資料

【測試總結】

　　第一階段測試結果非常出人意料，ADO.net和LINQ to SQL操作資料的時間都控制在0.5秒以内，非常的迅速，但是Entity Framework在添加這步表現非常差，由于這五步是連續測試，其中添加資料是第一步操作，而EF在在進行第一步操作的時候足足延遲了3秒鐘！這3秒鐘到底EF在做什麼？

　　從第二階段開始，性能的優劣就非常明顯的展現在我們面前，第二階段到第六階段，不論操作資料量的大小，圖中的耗時比例幾乎是相同的。Entity Framework無可争議的以極高的效率在三種方案中脫穎而出，而LINQ to SQL的龜速修改和删除操作消耗的時間幾乎是EF的10倍，ADO.net在添加資料上的表現實在不盡如人意，這也跟我們項目底層寫法有關。

　　從上面的測試結果可以看出，除去EF在初次操作資料是延遲的3秒鐘（初步認為是初始化時間），EF的平均效率是LINQ to SQL的6倍，是目前項目機制的4倍，這是非常可觀的效率提升，不難了解為什麼微軟幾乎放棄了LINQ to SQL，全力支援EF了。

第一次建立ObjectContext并查詢資料時耗費了大量的時間，原因是什麼？有沒有什麼優化的方法？本文将給出一個合理的解釋。

下面這個餅狀圖給出了第一次建立ObjectContext并用其通路資料庫時各種操作所占的時間比

從中可以看出僅僅View Generation一個操作就占用了56%的時間，不過令人欣慰的是，這個操作隻出現在第一次查詢的時候，之後生成好的View會被緩存起來供以後使用。一個View.cs檔案的樣本如下：

我們可以使用EDMGen2.exe來自己生成View.cs，然後把它加入到工程中編譯，這樣會大大縮減View Generation操作所占的時間比。根據ADO.NET TEAM 的測試，自己編譯View大概會節省28%的時間。不過我在自己電腦上測試的結果沒有那麼理想，大概是8%左右。

http://blog.csdn.net/hxwangcong/article/details/5598544