優化代碼時要選用正確的測試方法
2024-07-21 02:20:29
供稿：網友
想提高vb效率的時候，常用測試來檢驗算法的優劣，但測試本身的“算法”卻被忽略！這里我很想說一段“故事”：
我在研究一個alpha運算的代碼時，就感到了同樣的問題：他把vb算法與api中的alphablend做了比較，結果證明vb更快。因為我也寫過一個alpha運算的代碼，所以針對他的源碼做了分析，發現二者有兩個不同，
一是他使用的是了dib，而我的是基于ddb，所以他的速度很一致，而我的因涉及不同色深算法不同，自然速度也不一樣，16位色處理始終慢些；
二是他使用了safearray結構指針，而我沒有，我無法用這種指針的一個原因是，他的dib位圖是預先載入自己創建的dibsection的，創建時便已獲取了數據指針，這樣就會比ddb少了一步數組復制過程。
指針并不是vb的獨門絕技，難道，用了指針就會比c快？再看了一下那段代碼用的測試方法，我才明白：dib是預先載入的，計時的只是一個運算部分，alphablend當然沒有這個優先權，它雖然也是用這個dib，但它沒有其指針，它仍需先獲取這個dib數據，再處理，最后再輸出回這個dib，再由vb統一輸出到屏幕，這當然慢。
其實用dib處理的確簡單，因為可以統一位圖數據格式，一個算法便能適應所有色深。但我為什么后來沒用dib，原因就是一點：dib慢呀，alpha效果是一種屏幕動態效果，原始圖都是基于ddb的，所以實際應用中是不會有現成的dib可用的。
若使用dib，必需得有一次轉換，將ddb繪入新創建的dibsection，別小看了這一次轉換，我測試表明，用這種方式進行一次完整的alpha處理，ddb繪入dibsection的時間占整個處理時間的70%！！！
另一個讓我大為吃驚的是，單獨對運算部分計時，我發現用指針的算法，與我不用指針直接處理數組速度幾乎一樣。所以當把“從ddb做輸入源，到重新輸出回ddb”做為一個過程來看待時，我的ddb處理法比dib法快了3倍多，但仍遠慢于alphablend，我對vb的指針用法更開始茫然。
所以各種測試一定不要離開實際應用這個范圍，不然真會走入歧途。bluedog() 的幾個函數，除那個匯編外，與我在處理中使用的方法都一樣，但我是內置于處理過程中的，不用說肯定比函數調用要快；匯編那段估計是調用一個利用c做移位運算的函數，就象我對copymemory速度都感到失望一樣，做為一次函數調用，我對其速度也不敢抱太多幻想。
根據我反復測試的結果，我一直想推出一個讓很多人大跌眼鏡的結論：copymemory有時還沒有用循環從數組直接取值快！
以前認為它快的結論是源于對測試條件的誤解，在我們測試時，換有不同算法總是在調試環境下先進行比較的，在調試環境下用copymemory代替用循環從數組取值，會使速度明顯提高，為什么？因為copymemory是已經過編譯的函數！若循環也經過本機碼編譯，其就會比調用函數copymemory快了。因為它在同等執行方式下，省去了函數調用的開銷。
不過copymemory在數據增大時速度下降不明顯，而循環這方面就弱了，所以大數據還是建議用copymemory的，這個長度不好確定，由測試情況決定，一般32字節以上，還是值得調用一下函數的。
