Browse by Tags

dynamic 參數之效能損耗實測

依據 前篇文章 ：參數傳入 dynamic 會讓函式傳回值也變成 dynamic，導致無法使用 LINQ Lambda 運算式。文末提到，依據 方法多載（Method Overloading）與 dynamic 一文的研究心得，.NET 呼叫函式時若遇到參數為 dynamic 時，將改用System.Runtime.CompilerServices、System.CSharp.RuntimeBinder 命名空間物件與方法間接觸發，程序曲拆繁瑣許多。由此推測，參數傳入 dynamic 型別肯定會產生效能損耗...

Posted 27 August 2017 03:56 PM 由 Jeffrey | with no comments 5,102

Filed under: .NET, Performance

使用非同步處理提升資料庫更新速度

來自同事的資料庫程式效能調校案例一則。 情境為一支同步來源及目的資料表的排程，先一次取回來源及目的資料表，逐一檢查資料是否已存在目的資料表，若不存在即執行Insert，若存在則執行 Update 更新欄位。因 Insert/Update 之前需進行特定轉換，故難以改寫為 Stored Procedure。排程有執行過慢問題，處理四萬筆資料耗時近 27 分鐘。 程式示意如下： foreach (var src in srcList) { try { var target = findExistingData...

Posted 09 February 2017 08:49 PM 由 Jeffrey | 14 comment(s) 39,333

Filed under: .NET, Performance

迴圈比對條件的陣列長度該不該用變數?

前幾天看到關於陣列跑迴圈時，比對條件裡陣列長度改用變數提升執行效率的討論。亦即 for (int i = 0; i < array.Length; i++) ... 若改成 int c = array.Length; for (int i = 0; i < c; i++) ... 會不會變快? 支持變快的理由是比對條件會反覆執行，array.Length透過屬性取值會比直接存取變數耗時。 但有另一派 說法 : Some programmers believe that they can...

Posted 21 February 2013 09:44 PM 由 Jeffrey | 4 comment(s) 9,318

Filed under: .NET, Performance

【茶包射手日記】LINQ過量載入陷阱及.NET記憶體限制

今天處理了一件.NET服務故障案件。有個.NET開發的Windows服務，其任務為每隔幾分鐘查詢資料庫，取出待處理的作業項目，依其指示執行相關動作。狀況為資料庫仍有大量待處理項目，但服務未如預期取回資料逐筆消化。 幸運的是，程式設計時已加入頗為詳細的Log機制，很快地在Log檔發現記憶體不足錯誤訊息: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.   ...

Posted 09 October 2012 11:21 PM 由 Jeffrey | with no comments 11,518

Filed under: .NET, Trouble-Shooting, Performance

ODP.NET OracleBulkCopy

嫌棄使用OracleCommand批次更新大量資料效能不佳，爬文找到ODP.NET有個 OracleBulkCopy類別 支援將整個ADO.NET DataTable一次送至資料庫更新(與SQL 2008的 Table Value Parameter 有異曲同工之妙)，於是做了Lab測試效果。 在Oracle資料庫建了一個TABLE BIGONE (N DECIMAL(6,0), T NVARCHAR2(64))資料表，在.NET程式中產生五萬筆資料，分別使用以下兩種方法寫入資料庫: 1) 建立OracleCommand...

Posted 19 August 2011 07:19 PM 由 Jeffrey | 2 comment(s) 27,218

Filed under: ORACLE, .NET, Performance

Reflection執行效能測試

在寫類似Code Generator的功能，遇到一個抉擇點: 若要將DataRow的各欄位逐一映對到資料物件的各欄位上，該使用Reflection還是Hard-Coding? 使用 Reflection 方式(PropertyInfo)讀寫物件屬性可大幅簡化程式碼複雜度，但需付出效能上的代價。如 先前文章 所提，隨著CPU的運算能力愈來愈強大，效能代價的負面影響也會愈來愈小。只是在查詢資料過程中，DataRow轉換成資料物件的程序會被連續大量執行，恐怕又得另當別論。例如: 查詢取回10萬筆DataRow...

Posted 06 July 2011 11:17 PM 由 Jeffrey | 4 comment(s) 14,821

Filed under: .NET, Performance

用.NET展現多核威力(3) – 佛心TPL之Parallel.For好威

在 前一篇文章 裡，我們驗證了為每個CPU Core開一條獨立Thread並事先分攤好計算工作，可以讓巨量Log10計算程式飆出最高效能! 但是，仔細看看程式碼: int WORKER_COUNT = 2; Thread[] workers = new Thread[WORKER_COUNT]; int jobsCountPerWorker = MAX_COUNT / WORKER_COUNT; for ( int i = 0; i < WORKER_COUNT; i++) { int st...

Posted 22 January 2010 06:06 AM 由 Jeffrey | 14 comment(s) 43,860

Filed under: .NET, Performance

用.NET展現多核威力(2A) - 一核一緒補充包

在 前一篇多核研討文章 中，用了一個計算1000萬次Log10運算的範例驗證Thread數與Core相同時可以達到最佳效能，網友Google質疑以Log10計算當範例是否用能代表"以運算為主的大量作業"，在此做點補充說明。 我想若以茶包射手實事求是的精神，"以運算為主的大量作業"這個命題是有問題的，應該要修正成"不涉及非CPU資源競爭的大量純運算作業"更貼近原意。用白話來解釋，這裡假設的前題是---有一大堆運算工作要處理，每件運算工作彼此獨立可以同時進行...

Posted 20 January 2010 07:00 AM 由 Jeffrey | 3 comment(s) 12,760

Filed under: .NET, Performance

用.NET展現多核威力(2) - 一核一緒 王者之道?

在 前一篇文章 裡，我們陰了ThreadPool一下，把一個運算十分簡單，但是數量極其龐大的計算需求拆解成無數UserWorkItem交給ThreadPool執行，然後冷眼旁觀ThreadPool在lock機制的消磨下，慘敗給傻瓜都會的單一執行緒寫法，速度足足慢了七倍有餘... lock機制看來是最大的殺手。明明人手充足，卻規定所有人員必須排隊成一列輪流完成某個動作才能繼續工作，當完成工作本身所需的時間很短，則耗費在排隊的時間就顯得漫長而荒謬。這就是前一篇文章所點出的事實。 那麼，在這個案例中，我們應如何改善...

Posted 03 January 2010 08:39 AM 由 Jeffrey | 7 comment(s) 20,003

Filed under: .NET, Performance

用.NET展現多核威力(1) - 從ThreadPool翻船談起

在進入主題前，先來爆個料: 踢爆黑心程式碼，瞎忙半天幫倒忙!! 昨天我貼了一篇關於 匿名方法與具名方法效能比較 的文章，不知有沒有人發現到，其實裡面藏了一個天大的祕密!! Lambda寫法無損效能的結論是對的，但是，在這個範例裡用ThreadPool處理卻錯得離譜! 不信? 那我們先保留第二段的ThreadPool + Lambda寫法，但將第一段改成 for (int i = 0; i < TIMES; i++) NamedMethod(i); 換句話說，第一段程式不再管什麼鬼ThreadPool...

Posted 02 January 2010 08:23 AM 由 Jeffrey | 5 comment(s) 33,232

Filed under: .NET, Performance

Try Catch Block是否會影響效能?

跟網友在部落格上討論效能時提到一個 議題 --在迴圈中加入try...catch是否會影響效能? 依我的認知，try...catch只有在發生Exception時才會 嚴重危害效能 ，平時正常執行時，我們倒可以"幾乎忘了它的存在"。 不過，我過去似乎還真沒用測試驗證過這一點，既然聊到了，就順手寫幾行Code實測一番: using System; using System.Diagnostics; namespace TryCatchCost { class Program {...

Posted 20 December 2009 04:37 PM 由 Jeffrey | 4 comment(s) 16,953

Filed under: .NET, Performance

LINQ to XML vs XPath的簡單效能測試

如果你使用的平台是.NET 3.5，在操作XML文件時會有三種選擇: LINQ to XML, LINQ to XML with XPath以及傳統的XmlDocument。既然有三種選擇，排除個人主觀偏好，想知道哪一種做法的效能最好呢? 之前有個迷思，一直覺得LINQ表達方式友善，理論上會付出效能上的代價(正所謂有一好沒兩好)。所以有時針對複雜的元素查詢，我會using System.Xml.XPath，然後改用XPathSelectElements()查詢，直到無意間發現了一篇 談LINQ to...

Posted 15 December 2009 09:08 PM 由 Jeffrey | 3 comment(s) 17,506

Filed under: .NET, Performance

觀察LINQ to SQL DataContext的連線開啟時機

昨天的文章 發表後，有兩位網友提到了DataContext是否要加using的議題。 我接觸LINQ to SQL是由Scott Gu的 這幾篇文章 開始入門的，在他的範例中沒有特別提到using，我也自始就忽略DataContext有實做IDispose這件事。雖然用using包住絕對有益無害(只要小心using中間過程如將DataContext傳到外部，要留意using結束後外部就不可再繼續叫用)，但我倒認為DataContext裡的Connection應該不是一new DataContext就建立一條連線不放...

Posted 19 October 2009 02:57 AM 由 Jeffrey | 14 comment(s) 27,997

Filed under: .NET, Performance, Linq, SQL 2008

文章-StringBuilder與String的字串相接效能大車拼

一直以來，我對StringBuilder懷有很深的歉意。 明明StringBuilder在設計上，就是針對String在字串處理上的無效率做了諸多改良，偏偏在本站幾次登場: 要不就是在靜態字串相接上 輸到灰頭土臉 ；再不就是在Replace比試中 陰溝裡翻船 。被不熟.NET的人瞧見了，還誤以為StringBuilder是隻紙老虎哩... 在此鄭重聲明，StringBuilder真的是鐵打硬漢，只是剛好前述的兩個案例比的是繡花跟炒菜，所以才.... 在 StringBuilder串接字串的迷思 一文中...

Posted 07 September 2009 03:11 AM 由 Jeffrey | 19 comment(s) 22,283

Filed under: .NET, Performance

Smart C# Compiler

前陣子幫同事追查問題，由於懷疑主機上的程式版本有誤，便找來Source Code，與Reflector反編譯(Decompile)主機上DLL得到的Code比較，在一段程式上發現了小小的差異: Souce Code裡是先將DropDownList的SelectedValue先存到變數中，再將該變數當成呼叫另一個函數的參數；而Reflector中看到的卻是直接將DropDownList.SelectedValue直接被當成呼叫另一函數的參數。 程式寫法的差異，讓人懷疑上線的程式版本有誤。但同事印象中從頭到尾不曾用過這種寫法...

Posted 09 January 2008 08:58 AM 由 Jeffrey | 7 comment(s) 16,817

Filed under: Tips, .NET, Performance

搜尋