Browse by Tags

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 | with no comments

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

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

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

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)

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)

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)

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

Filed under: Performance, Linq

CODE-Javascript測速用碼錶

前陣子我分享了關於 JS效能調校的經驗 ，IE8 Dev Tool是個很方便的工具。不過，不是每種瀏覽器上都有Profiler可用，若想在不同瀏覽器上都能精確地量測某段操作的時間長短，寫一個Javascript版的 Stopwatch 計時碼錶應是最直接有效的方法。所以我寫了一個JS計時碼錶---darkStopWatch: //Declare a stopWatch "class" function darkStopWatch(timerName) { this .timerName...

Posted 16 June 2009 07:22 AM 由 Jeffrey | 3 comment(s)

Filed under: Javascript, Performance

好用到掉渣的IE8 Developer Tools--JS效能調校經驗

對我來說，IE8最讓人興奮的新功能非"IE8 Developer Tools"莫屬!! (沒騙你們，我有文章為憑: 1 2 3 ) 上市後，IE8立即取代Firefox成為我開發網頁時的主力測試工具，也開始體驗它的強大威力。 像是可任意下指令的Console視窗我就超愛，把整個網頁玩弄於股掌之間的感覺真好~~ 就拿新聞網站為例，先用 上次提過的技巧 載入jquery-1.3.2.js，用HTML Tab的工具觀察DOM結構，然後可以在Script Tab的Conosle區一行一行下指令...

Posted 08 June 2009 06:40 AM 由 Jeffrey | 8 comment(s)

Filed under: Javascript, Performance, IE, jQuery

KB-Transaction in Linq to SQL

關於Ling to SQL如何處理交易，一直有個疑問 -- 當多筆資料的更新動作必須包成Transaction時，在Linq to SQL中應如何處理? 花了點時間研究，心得如下: 當連續進行多筆資料更新，再一次DataContext.SubmitChanges();，預設Linq to SQL會自動將這些INSERT/UPDATE/DELETE包成一個Transaction。例如: var order1 = ( from o in db.Orders where o.OrderID == 10248...

Posted 14 May 2008 07:26 AM 由 Jeffrey | 5 comment(s)

Filed under: KB, Performance, Linq

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)

Filed under: Tips, .NET, Performance

搜尋