百寶箱剖析ADO.NET Entity框架性能
#T#在網上看到一篇文章是關于講解ADO.NET Entity框架。看了之后深有體會，在這里我就把我所看到的和大家在一起分享一下。ADO.NET團隊最近討論了ADO.NET Entity框架的各種性能特征。ADO.NET Entity框架在12月已經進入它的第三個beta版本，自那時起開發(fā)團隊就開始為開發(fā)人員提供了使用該框架的相關信息。而現(xiàn)在，則為開發(fā)人員提供了框架性能方面的信息。
本文鞭辟入里地介紹了ADO.NET Entity框架的性能，演示了如何提高簡單查詢速度的方法，并闡釋了框架的性能特征。需要重點指出的是，當一個抽象層或者類似EDM（譯注：指Entity Data Model）的模塊被用來轉換數(shù)據(jù)庫的關系樣式時，會帶來一定的性能損失。
查詢與結果
本文使用了NorthWind數(shù)據(jù)庫作為模型，并創(chuàng)建了一個簡單查詢：
- (NorthwindEntities ne = NorthwindEntities()) { (Order o ne.Orders) { i = o.OrderID; } }
測試時，我們的每個查詢對整個848行數(shù)據(jù)進行了10次遍歷。結果很有意思，第1次運行時耗費了4241毫秒，而接下來的每次運行則平均耗費13毫秒左右的時間。最耗時的一部分內容是ObjectContext的創(chuàng)建，而在執(zhí)行任意一個訪問數(shù)據(jù)庫的操作時，都會有一些耗時的操作發(fā)生。耗時百分比值最大的是視圖生成，它達到了驚人的56%。既然視圖生成是造成性能損耗的罪魁禍首，那么開發(fā)人員最好是使用命令行工具EDM生成器（EdmGen.exe），運行時需要加上視圖生成命令參數(shù)（/mode:ViewGeneration），它的輸出內容為一個代碼文件（C#或者VB.NET），可以包含在項目中。視圖的預生成可以將啟動時間降低到2933毫秒，而對于循環(huán)遍歷操作，整個時間可以降低28%。生成視圖并隨著應用程序一起發(fā)布是提高性能的妙方，但其缺點則在于視圖不再是動態(tài)的，一旦模型發(fā)生改變，就需要重新生成以保持同步。
ADO.NET Entity框架查詢性能
需要指出的是關于性能的主要設計要素是查詢緩存。一旦執(zhí)行了查詢，它的一部分內容就被維持在全局緩存中。由于查詢與元數(shù)據(jù)緩存的存在，使得第二次運行的執(zhí)行速度總是比第一次運行快。例如，如下的Entity SQL查詢：
- (PerformanceArticleContext ne = PerformanceArticleContext())
- { ObjectQuery<Orders> orders = ne.CreateQuery<Orders>();
- (Orders o orders) { i = o.OrderID; } }
第一次運行該查詢耗時179毫秒，但下一次運行則只耗費了15毫秒的時間。首次運行與后續(xù)運行在執(zhí)行方面的區(qū)別在于它構建了能夠為執(zhí)行傳遞provider的命令樹（command tree）。
ADO.NET Entity框架之LINQ查詢在執(zhí)行方式上與Entity SQL查詢相似。例如，下面的查詢：
- (PerformanceArticleContext ne = PerformanceArticleContext())
- { var orders = from order ne.Orders select order;
- (Orders o orders) { i = o.OrderID; } }
首次執(zhí)行LINQ查詢耗時202毫秒，而隨后的執(zhí)行耗時18毫秒，兩者的差距還要低于Entity SQL。可以看到，使用編譯了的LINQ查詢對于性能的提高更為明顯。編譯LINQ查詢的好處在于它構建了表達樹（expression tree），當查詢被編譯時，后續(xù)的執(zhí)行就不需要重建表達樹了。編譯的LINQ查詢代碼看起來像這樣：
- Func<PerformanceArticleContext, IQueryable<Orders>> compiledQuery
= CompiledQuery.Compile((PerformanceArticleContext ne) => (from o ne.Orders select o));- (PerformanceArticleContext ne = PerformanceArticleContext()) { (Orders o compiledQuery(ne)) { i = o.OrderID; } }
注意，PerformanceArticleContext是一個委托。對于編譯了的LINQ查詢而言，第一次執(zhí)行耗時305毫秒，而隨后的執(zhí)行時間則為15毫秒。結果并不驚人，值得關注的是編譯的LINQ查詢比之常規(guī)方式的LINQ查詢，執(zhí)行時間少了3毫秒。或許對于幾個查詢而言，這算不上什么，但如果有數(shù)以千計的查詢，這樣的性能提升就倍顯價值所在了。
