Browse by Tags

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

前幾天看到關於陣列跑迴圈時，比對條件裡陣列長度改用變數提升執行效率的討論。亦即 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)

Filed under: .NET, Performance

關於IQueryable<T>特性的小實驗

ASP.NET Web API支援OData，可以藉由URL加註$filter、$orderby、$skip、$top參數，對資料進行條件篩選、排序、分頁等加工(關於ASP.NET Web API OData特性，可參見KKBruce的 文章 )。而要啟用OData，有項重要前題是回傳資料型別必須為IQueryable<T>，而非一般LINQ常用的IEnumerable<T>。 對於List<T>、T[]等保存在記憶體的資料結構，傳回IQueryable<T>充其量只是要多一層...

Posted 23 October 2012 12:08 AM 由 Jeffrey | with no comments

Filed under: Performance, Linq, Entity Framework

【茶包射手日記】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

Filed under: .NET, Trouble-Shooting, Performance

打破沙鍋-AJAX POST比GET效率差?

故事要從點部落看到的 一篇文章 說起，該文章引薦了另一篇文章: 如何有效的提升網站的效能 - 12項建議 ，提出不少網頁前端設計上的效能提示，不過其中第8點: 在使用Ajax時，請盡量以GET的方式進行請求，以POST的方式將造成雙倍的要求次數 卻讓人有些疑惑，依我對HTTP GET與POST運作原理的理解，無法解釋Request數變兩倍的理由。於是在噗浪上 討論了一番 ，發現許多人跟我有相同的疑問，直到JavaScript神人-費拉諾蘭大公現身，指引眾人一條明路，在Yahoo Developer...

Posted 10 June 2012 07:18 AM 由 Jeffrey | 3 comment(s)

Filed under: Performance, AJAX

當心LINQ搜尋的效能陷阱

對於長年與資料庫、SQL語法打交道的開發者來說，LINQ語法有無比的親切感! 當要在List<SomeClass>集合中找尋特定物件時，寫成    form o in SomeList where o.Col1 == "A" && o.Col2 == "B" select o 是再自然也不過的事。乍看之下，反正List<SomeClass>已被存在記憶體，無須顧忌反覆查詢資料庫所產生的連線成本，而where條件比對又十分直覺易懂...

Posted 20 October 2011 12:55 AM 由 Jeffrey | 8 comment(s)

Filed under: Performance, Linq

再探ASP.NET大排長龍問題

在 MaxConnectionsPerServer實驗 中，發現一個過去被忽略的問題: 原來同一個Session下， 啟用Session的ASP.NET網頁，因鎖定限制有可能出現單一時間內只能有一個Request被處理的情況 。換句話說，即便我們使用非同步方式同時發出10個對ASP.NET網頁的Request，若該ASP.NET網頁涉及Session，這10個Request將不會同步執行，而是10個Request排成一列，一個執行完再執行下一個。 回到上回MaxConnectionsPerServer...

Posted 27 August 2011 11:30 AM 由 Jeffrey | 9 comment(s)

Filed under: ASP.NET, 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 | 1 comment(s)

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)

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 | 4 comment(s)

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)

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)

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)

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 | 9 comment(s)

Filed under: .NET, Performance

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

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

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

Filed under: .NET, Performance

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

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

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

Filed under: .NET, Performance

搜尋