轉(zhuǎn)載自：http://blog.csdn.net/hxwangcong/article/details/5598544

第一次讀寫10條數(shù)據(jù)

第二次讀寫10條數(shù)據(jù)

操作100條數(shù)據(jù)

操作1000條數(shù)據(jù)

操作10000條數(shù)據(jù)

操作100000條數(shù)據(jù)

【測試總結(jié)】

　　第一階段測試結(jié)果非常出人意料，ADO.net和LINQ to SQL操作數(shù)據(jù)的時間都控制在0.5秒以內(nèi)，非常的迅速，但是Entity Framework在添加這步表現(xiàn)非常差，由于這五步是連續(xù)測試，其中添加數(shù)據(jù)是第一步操作，而EF在在進(jìn)行第一步操作的時候足足延遲了3秒鐘！這3秒鐘到底EF在做什么？

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

　　從上面的測試結(jié)果可以看出，除去EF在初次操作數(shù)據(jù)是延遲的3秒鐘（初步認(rèn)為是初始化時間），EF的平均效率是LINQ to SQL的6倍，是當(dāng)前項(xiàng)目機(jī)制的4倍，這是非?？捎^的效率提升，不難理解為什么微軟幾乎放棄了LINQ to SQL，全力支持EF了。

【深入分析為什么第一次執(zhí)行Entity Framework非常慢的原因】（轉(zhuǎn)）

第一次創(chuàng)建ObjectContext并查詢數(shù)據(jù)時耗費(fèi)了大量的時間，原因是什么？有沒有什么優(yōu)化的方法？本文將給出一個合理的解釋。

下面這個餅狀圖給出了第一次創(chuàng)建ObjectContext并用其訪問數(shù)據(jù)庫時各種操作所占的時間比

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

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