-
網友 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...
-
在 前一篇文章 裡，我們驗證了為每個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...
-
在 前一篇多核研討文章 中，用了一個計算1000萬次Log10運算的範例驗證Thread數與Core相同時可以達到最佳效能，網友Google質疑以Log10計算當範例是否用能代表"以運算為主的大量作業"，在此做點補充說明。 我想若以茶包射手實事求是的精神，"以運算為主的大量作業"這個命題是有問題的，應該要修正成"不涉及非CPU資源競爭的大量純運算作業"更貼近原意。用白話來解釋，這裡假設的前題是---有一大堆運算工作要處理，每件運算工作彼此獨立可以同時進行...
-
在 前一篇文章 裡，我們陰了ThreadPool一下，把一個運算十分簡單，但是數量極其龐大的計算需求拆解成無數UserWorkItem交給ThreadPool執行，然後冷眼旁觀ThreadPool在lock機制的消磨下，慘敗給傻瓜都會的單一執行緒寫法，速度足足慢了七倍有餘... lock機制看來是最大的殺手。明明人手充足，卻規定所有人員必須排隊成一列輪流完成某個動作才能繼續工作，當完成工作本身所需的時間很短，則耗費在排隊的時間就顯得漫長而荒謬。這就是前一篇文章所點出的事實。 那麼，在這個案例中，我們應如何改善...
-
在進入主題前，先來爆個料: 踢爆黑心程式碼，瞎忙半天幫倒忙!! 昨天我貼了一篇關於 匿名方法與具名方法效能比較 的文章，不知有沒有人發現到，其實裡面藏了一個天大的祕密!! Lambda寫法無損效能的結論是對的，但是，在這個範例裡用ThreadPool處理卻錯得離譜! 不信? 那我們先保留第二段的ThreadPool + Lambda寫法，但將第一段改成 for (int i = 0; i < TIMES; i++) NamedMethod(i); 換句話說...
-
跟網友在部落格上討論效能時提到一個 議題 --在迴圈中加入try...catch是否會影響效能? 依我的認知，try...catch只有在發生Exception時才會 嚴重危害效能 ，平時正常執行時，我們倒可以"幾乎忘了它的存在"。 不過，我過去似乎還真沒用測試驗證過這一點，既然聊到了，就順手寫幾行Code實測一番: using System; using System.Diagnostics; namespace TryCatchCost { class Program {...
-
如果你使用的平台是.NET 3.5，在操作XML文件時會有三種選擇: LINQ to XML, LINQ to XML with XPath以及傳統的XmlDocument。既然有三種選擇，排除個人主觀偏好，想知道哪一種做法的效能最好呢? 之前有個迷思，一直覺得LINQ表達方式友善，理論上會付出效能上的代價(正所謂有一好沒兩好)。所以有時針對複雜的元素查詢，我會using System.Xml.XPath，然後改用XPathSelectElements()查詢，直到無意間發現了一篇 談LINQ to...
-
昨天的文章 發表後，有兩位網友提到了DataContext是否要加using的議題。 我接觸LINQ to SQL是由Scott Gu的 這幾篇文章 開始入門的，在他的範例中沒有特別提到using，我也自始就忽略DataContext有實做IDispose這件事。雖然用using包住絕對有益無害(只要小心using中間過程如將DataContext傳到外部，要留意using結束後外部就不可再繼續叫用)，但我倒認為DataContext裡的Connection應該不是一new DataContext就建立一條連線不放...
-
一直以來，我對StringBuilder懷有很深的歉意。 明明StringBuilder在設計上，就是針對String在字串處理上的無效率做了諸多改良，偏偏在本站幾次登場: 要不就是在靜態字串相接上 輸到灰頭土臉 ；再不就是在Replace比試中 陰溝裡翻船 。被不熟.NET的人瞧見了，還誤以為StringBuilder是隻紙老虎哩... 在此鄭重聲明，StringBuilder真的是鐵打硬漢，只是剛好前述的兩個案例比的是繡花跟炒菜，所以才.... 在 StringBuilder串接字串的迷思 一文中...
-
我喜歡LINQ to SQL的簡潔，就拿更新資料庫某筆資料這件事來說，你可以忘記SqlConnection、丟掉SqlCommand、抛下SqlParameter，就搞定整個更新動作，對寫慣ADO.NET的人來說，實在是件不可思議的事。 像下面這個例子，寫一段LINQ配上Single()取得資料物件，重新指定值，然後SubmitChanges()就完成了ID=2 Player資料的CreateTime欄位更新。有種袖子都還沒捲起來，敵人就忽然自已暴斃的莫名爽快。 protected void Page_Load...
-
前陣子我分享了關於 JS效能調校的經驗 ，IE8 Dev Tool是個很方便的工具。不過，不是每種瀏覽器上都有Profiler可用，若想在不同瀏覽器上都能精確地量測某段操作的時間長短，寫一個Javascript版的 Stopwatch 計時碼錶應是最直接有效的方法。所以我寫了一個JS計時碼錶---darkStopWatch: //Declare a stopWatch "class" function darkStopWatch(timerName) { this .timerName...
-
對我來說，IE8最讓人興奮的新功能非"IE8 Developer Tools"莫屬!! (沒騙你們，我有文章為憑: 1 2 3 ) 上市後，IE8立即取代Firefox成為我開發網頁時的主力測試工具，也開始體驗它的強大威力。 像是可任意下指令的Console視窗我就超愛，把整個網頁玩弄於股掌之間的感覺真好~~ 就拿新聞網站為例，先用 上次提過的技巧 載入jquery-1.3.2.js，用HTML Tab的工具觀察DOM結構，然後可以在Script Tab的Conosle區一行一行下指令...
-
關於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...
-
前陣子幫同事追查問題，由於懷疑主機上的程式版本有誤，便找來Source Code，與Reflector反編譯(Decompile)主機上DLL得到的Code比較，在一段程式上發現了小小的差異: Souce Code裡是先將DropDownList的SelectedValue先存到變數中，再將該變數當成呼叫另一個函數的參數；而Reflector中看到的卻是直接將DropDownList.SelectedValue直接被當成呼叫另一函數的參數。 程式寫法的差異，讓人懷疑上線的程式版本有誤。但同事印象中從頭到尾不曾用過這種寫法...
-
.NET的開發效能提示中，有一條原則是"不要把try...catch當成正常流程"。今天在修改前人程式時，看到一個挺經典的真實案例，跟大家分享一下。 1: static void avoidTryCatchDemo( string file) 2: { 3: StreamReader sr = 4: new StreamReader(file); 5: System.Diagnostics.Stopwatch sw = 6: new System.Diagnostics.Stopwatch...