Browse by Tags

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) 23,403

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) 13,942

Filed under: .NET, Performance

ORACLE LIKE效能調校經驗一枚

在我的認知裡，資料庫查詢在使用LIKE 'ABC%'時還是可以引用Index，但若變成LIKE '%ABC%'，或LIKE '%ABC'，就註定只能Table Scan，把整張資料表的每一筆撈出來比對。 最近幫忙看一個Oracle資料庫查詢效能不佳的個案，學到不同的處理經驗: SELECT C1, C2, C3, C4, C5, C6, C7 FROM myTable WHERE C1 = 'XXXX' AND C2 LIKE 'ABC...

Posted 06 December 2010 09:08 PM 由 Jeffrey | 5 comment(s) 16,411

Filed under: ORACLE, Performance

關於SQL語法IN條件式的效能

前些時候，在做資料查詢時發現ORACLE支援多欄位IN條件的簡化寫法: SELECT * FROM T1 WHERE (C1,C2) IN (SELECT C1,C2 FROM T2) 當下覺得它好簡潔，SQL沒有真是可惜，便在噗浪上 嘟嚷 了兩句，獲得一些回饋: 保哥 提到SQL有EXISTS可以取代， hector ♂ lee 則提醒IN可能存在的效能疑慮... 而這些資訊恰巧幫助我對於IN條件查詢效能有了新的體認，讓我不禁要說: 有網路社群真好! 應用上次學會的簡潔IN多欄位寫法，我搞出了類似以下的SQL語句...

Posted 29 October 2010 07:07 AM 由 Jeffrey | 3 comment(s) 51,834

Filed under: ORACLE, Performance

IISLog應用案例分享: 統計特定網頁的平均執行時間

【案例需求】 使用者反應近來某些網頁程式"執行時間好像變久了"。OP希望由IIS Log中取得相關數字證實，釐清是程式效能變差需要調校，還是使用者需要一本金剛經培養耐性? 【分析程序】 取得網頁所在IIS近三個月的IIS Log，ex1002*.log, ex1003*.log, ex1004*.log 使用 Visual Log Parser (好物! 可參考保哥的 介紹文 )進行查詢，語法為: select to_string( date , 'yyyyMMdd'...

Posted 02 May 2010 07:47 AM 由 Jeffrey | 2 comment(s) 15,793

Filed under: Performance, IIS

在.NET 3.5中使用Parallel.For()

網友 KENCHAO 問到" 好威的Parallel.For 可以用在.NET 3.5上"嗎? 微軟在Task Parallel Library CTP版本時代 ，曾提供過相容於.NET 3.5的Microsoft Parallel Extensions for .NET Framework 3.5。但找了一下，官方似乎已不再提供該版本的下載... 但是別氣餒，依據MS Parallel Programming RD小組在2009年11月的PO文，有一個來自個 DevLabs...

Posted 05 February 2010 09:25 PM 由 Jeffrey | 1 comment(s) 14,858

Filed under: 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) 41,787

Filed under: .NET, Performance

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

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

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

Filed under: .NET, Performance

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

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

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

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) 30,150

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) 15,903

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) 16,407

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) 24,343

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) 20,849

Filed under: .NET, Performance

從LINQ to SQL的"一行更新法"聊起

我喜歡LINQ to SQL的簡潔，就拿更新資料庫某筆資料這件事來說，你可以忘記SqlConnection、丟掉SqlCommand、抛下SqlParameter，就搞定整個更新動作，對寫慣ADO.NET的人來說，實在是件不可思議的事。 像下面這個例子，寫一段LINQ配上Single()取得資料物件，重新指定值，然後SubmitChanges()就完成了ID=2 Player資料的CreateTime欄位更新。有種袖子都還沒捲起來，敵人就忽然自已暴斃的莫名爽快。 protected void Page_Load...

Posted 14 July 2009 02:58 AM 由 Jeffrey | with no comments 16,193

Filed under: Performance, Linq

搜尋