none
對Entity Framework Performance 抱怨以及建議. RRS feed

  • 一般討論

  • 當Entity Framework v1.0 出來時, 我很高興的使用這技術應用在公司商業營運上,

    經過一連串的使用下, 結果卻是給我沈重的打擊~

    雖然EF 架構目標很贊, 但是執行效能卻是其差到無法忍受的地步. (我也知道ORM多少會犧牲一點效能. 但也不應該慢到離譜.)

    舉例來說我使用Sql Command 存取Entity 資料要花10ms.

    但使用Entity Framework 存取卻得花上10倍以上的時間, 變成100ms.

    而改用Linq to SQL 也只能快上一些些. 也是得花上9倍以上的時間. 90ms.

    我也尋找各種各樣的方法來加速Entity Framework,

    例如:CompiledQuery.Compile, NoTracking, Lazy Loading, Cache... 各式各樣的加速技巧. 簡直到了無所不用其極的地步.

    但是, 最後我輸了.... 被打敗, 因為換來的結果就是程式碼變得很難以閱讀, 明明很簡單的只要一道指令(from tb in db.Table where tb.Name==name select tb).FirstOrDefault()

    卻非得加上各式各樣的與商業邏輯無關的加速程式碼. 才能達到我要的效能要求.

    最後我只好放棄Entity Framework, 改用我自己寫的Custom Linq Provider來取代Linq to SQL和Entity Framework.

    一改用自行寫的Custom Linq Provider速度上就飛快, 可以逼近Sql Command 的存取速度.

    最重要的一點就是可以專心在商業邏輯上, 輕輕鬆鬆的寫(from tb in db.Table where...) 一道, 不需要理會什麼 CompiledQuery.Compile, NoTracking, Cache...

    Custom Linq Provider 會自動CompiledQuery.Compile, Cache 等技巧來加速.

    但是Custom Linq Provider 非常不好寫, .NET 也沒有提供Linq Expression to TSQL Tree Parser, 讓我可以更專心在轉譯各式各樣的T-SQL 指令.

    讓我更容易的寫出Custom Linq to Oracle,Custom Linq to SQL,Custom Linq to MySQL....

    所以我強烈的建議微軟以下幾點

    1. 能不能快點改善Entity Framework 的效能? 明明有CompiledQuery.Compile, Cache 這些東西, 卻又不內建在裡面,

    省得我們只能看的到EF 技術, 卻又無法放心地使用在商業上. 就只有一個原因--- "慢慢慢"....

    2. 提供Linq Expression Tree Convert to SQL Tree Parser ISqlTranslator 之類的, 讓我們可以制定各式各樣的Translation SQL 出來.

    即使到現在VS2010 出來, Entity Framework 4, 我也不敢使用它了..... 只能用來負載要求很輕的商業邏輯上. 但這樣一來就得寫兩套程式碼....

    PS: 難道這裡沒有人抱怨EF 效能太差的問題嗎?  希望強烈地報上去給EF技術團隊去改善.

    • 已變更類型 Lolota Lee 2010年5月27日 上午 07:53
    2010年5月26日 上午 05:28

所有回覆

  • 呃, 可能我太老派, 都還用ADO.NET處理這樣的東西,所以對EF的效能問題我倒是沒有注意過.

    不過有點要說明的是論壇雖然是微軟架的, 不過活動的網友許多都是民間網友 (我也是).

    關於產品的改善建議, 微軟有提供一個更好的管道, https://connect.microsoft.com/   .歡迎多加利用.


    以下是簽名檔, 請勿沒事對號入座
    MSDN 文件庫很重要
    回應幫助你的人是一種禮貌, 良好的禮貌有助於激發大家對你問題回應的熱情
    進步的人會找尋自己程式中的缺點,半桶水則把自己程式的錯誤推到不相干事物的身上
    2010年5月26日 上午 05:42
  • Hi,您好:

    你的抱怨不難理解,因為所有ORM產品都有相同的抱怨,Performance問題是ORM的原生之罪,所以幾乎沒有人在比較各ORM間的效能差異,因為這沒意義,通常功能越齊全的ORM效能畢竟越差,所以目前除了全ORM的解決方案外,也有一些廠商出半ORM的解決方案(就是由程式開發者手動處理SQL Command),相對的越接近SQL彈性越小,效能越高,反之相同.

    並非我幫微軟說話,因為目前在.Net真正可行的純ORM方案只有兩個NHibernate與EF,其他的看看就好.這兩個我目前都有系統使用,也都很深入了解其架構,甚至修改了某些SourceCode或做了一些Library來延展使用,我在評估ORM產品的出發點是功能為先,效能其次.目前因為NHibernate對於Linq整合度還未完整.而看起來EF將式微軟未來的主力,所以大致上我已不使用NHibernate改向EF.不過我不會針對兩者作效能的評估,因為功能各有其優缺點,所以視情況兩者會有不同的結果.

    在很多篇EF提問開頭我都強調一件事,EF並不是用來取代ADO.Net目前的EF來式個ORM產品,ORM的目的在解決OO對關聯式資料庫存取的一個封裝產品.
    所以決定使用EF的前提是本身的開發模式要採用物件導向模式開發,如果採用傳統程序式方式撰寫ORM產品的問題弊遠大於利,尤其當專案越來越大時.
    使用OO撰寫很多問題自然會解決,因為在開發上的模式完全不同,譬如你可以參考這兩篇文章.如果能明白文章方式的涵意就會更深入了解EF的真正用途所在.

    http://www.dotblogs.com.tw/programlin/archive/2010/05/18/15315.aspx
    http://www.dotblogs.com.tw/programlin/archive/2010/05/20/15354.aspx

     

    對於ORM的應用有興趣可以多多討論.

     

     

     

    2010年5月26日 上午 06:22
  • 謝謝Bill Chung <abbr class="affil"> 提供的微軟</abbr> 產品的改善建議, 要不然我還真的找不到這個連結, (PS:我申訴上去了, 不知道微軟肯不肯接納改善)

     

    Dear programlin:

    ORM 我當然同意您的看法: "ORM的目的在解決OO對關聯式資料庫存取的一個封裝產品."  我需要這種OO技術,

    就是因為我的專案非常大, 所以用OO來解決, 但是不幸地這個專案卻又需要"效能", 所以我才自行撰寫ORM Provider來改善.

    Custom Linq to SQL功能上跟MS Linq to SQL ORM完全一樣, 但又不失SQL Command效能. 所以並非完全絕對是 "通常功能越齊全的ORM效能畢竟越差" ~

     

    我並非想要比較各種ORM效能, 主要想說的是, 微軟Provider 絕對有很大的改善空間, 我的Provider 都可以做到, 沒有道理微軟的ORM Provider 做不到基本的效能要求.

    我所希望的就是ORM 該有的效能要達到基本要求. 而不是慢到烏龜般的速度那麼離譜. 當然一開始我不敢奢求能像子彈一樣快, 但起碼要像兔子一樣快.

    (最起碼不要和ADO.NET Mapping Object 相差那麼離譜才對.)

    2010年5月26日 上午 07:25
  • Custom Linq to SQL的做法其實就是我上面所提的半套的ORM解決方案,由程式設計師自行決定如何轉譯ROM所對應的SQL Command.
    而當你採用這種方式就會失去如EF所提供的延遲載入等相關機制,所以我才會有"通常功能越齊全的ORM效能畢竟越差"的說法.

    但產品的改善是可建議的.像EF4對於EF在轉譯的SQL語法有相當大的差異,所有純ORM的產品最大的效能瓶頸都在於如何將轉換的SQL語法更貼近直接下達的SQL Command.但不幸的要通用且要自動這點就很難完全達成,只能盡量.

    此外上面我有提到採用OO配合ORM效能問題其實並不是重點,若確實採用OO方式來開發架構,原則上如技術使用EF,在專案中如果設計得當很多地方可以用架構解決問題,致使使用到LINQ join語法或其他複雜查詢的機會幾乎趨近於0.大多數情況都是select + where的語句,轉譯出來的解決也就相當接近於直接下達的SQL Command.

    但一個OO架構的程式並不代表所有資料存取層都一定要透過ORM機制,像報表這類東西就不適用,反而需要直接下達SQL command.但只要架構設計得好,並不會產生太大的維護上問題.

     

    因此目前的ORM產品尚沒有一家廠商有所謂完美的解決方案,因為尚未找到一個方式能夠完美的取代SQL command且又能達到OO的好處.因為關聯式資料庫本身與OO就有些矛盾問題.
    這問題要徹底解決只能看未來的OODB(物件導向資料庫)的發展趨勢了,只是目前的OODB大多還是止於學術研究,能用的成品幾乎等於0.當OODB成熟,自然就不會有ORM這種中介程式的存在.只是看起來是個遙遠的未來.

     

     

    2010年5月27日 上午 12:41
  • 也許是因為您沒有注重EF效能所以不知道EF 效能真正的問題所在, 就算你改用半套ORM(Linq to SQL), 它也是跟EF 一樣慢到離譜.

    即使半套ORM還是全套ORM, 他們都有許多效能問題, 我所說的EF 速度慢並不是卡在你認為 "最大的效能瓶頸都在於如何將轉換的SQL語法更貼近直接下達的SQL Command."

    就算即使你給他原生Sql Command 給 EF 去跑, EF 也是照樣會慢到離譜. EF 速度慢的癥結問題而是卡在其它的地方~

    在我認知裡EF ORM絕對不會慢到離譜, 我也改寫EF Provider, 結果就是比MS EF Provider 快.

     

    1. EF轉換至SQL Command步驟速度過慢, 即使每次查詢同樣的Query, EF 都還要重複地再轉換一次, 所以.NET 提供 CompiledQuery.Compile

    2. EF Add / Delete / Update 這種簡單的功能, 居然比Sql Command還慢上10倍. 你也可以查看EF 產生的Add / Delete / Update 轉換後的SQL Command.

    用這些轉換的SQL 來自行用SqlCommand (即使加上一大堆Convert Entity Data to SqlParameter)去跑, 也比EF 快上數倍

    3. 族繁不足備載....

     

    一開文我也說過: 例如:CompiledQuery.Compile, NoTracking, Lazy Loading, Cache... 各式各樣的加速技巧. 簡直到了無所不用其極的地步.

    只要用上這些技巧, EF 速度絕對可以和SQL Command 匹敵, 但微軟應該秉持著"Do more with less" 的精神, 把這些雜七雜八的加速功能,

    直接內建在EF 裡面.  這樣一來EF 才是真正的有達到基本效能的要求.

    2010年5月28日 上午 07:22
  • 不妨試用一下 Entity Framework 4...
    以下為簽名檔,請勿對號入座:
    初學不是問題,但用不正確的態度來問問題,那就是很大的問題。
    請不要藉新手之名行小白之實,否則只會讓更多無辜的新手得不到幫助而已。
    如果不知道什麼是小白,請參閱:何謂小白
    2010年5月28日 上午 07:34
    版主
  • 自從用EF1 之後, 就不斷地被使用者攻擊,
    花了大量的精神和時間在加強Performance上.
    已經沒有力氣再試EF4 了....

    有誰真正試過EF4 究竟有沒有長進? 和EF1 比較起來有快嗎?
    快到多少程度?
    2010年5月28日 上午 07:51
  • 不是每個使用者都和你有相同的環境,在我的電腦上測很快,未必在你的環境就很快。
    所以最好你自己還是做個簡單的 Lab 來測試。


    以下為簽名檔,請勿對號入座:
    初學不是問題,但用不正確的態度來問問題,那就是很大的問題。
    請不要藉新手之名行小白之實,否則只會讓更多無辜的新手得不到幫助而已。
    如果不知道什麼是小白,請參閱:何謂小白
    2010年5月28日 上午 11:47
    版主
  • 不知道在你的電腦測試有多快?

    2010年6月1日 上午 11:58