留下點(diǎn)回憶
程序員當(dāng)然要說代碼了，代碼是程序員的一切，離了代碼說其他都是假的，我這里從一段代碼開始。
這段代碼的目的是一個(gè)與圖形相關(guān)的操作，這里省略了許多代碼，所以不可能編譯；其基本的含義是從一個(gè)緩沖區(qū)復(fù)制到目標(biāo)緩沖區(qū)pSampling。其中m_imgWidth和m_imgHeight表示圖象的寬度和高度，m_lineBytes表示4個(gè)字節(jié)對(duì)齊的一行像素的字節(jié)數(shù)。
我們知道BMP文件的像素要求每行的最終字節(jié)數(shù)必須是4個(gè)倍數(shù)。如果圖象寬度是4的倍數(shù)，不用仇是沒有問題的；如果不是4的倍數(shù)，例如：129，而且每個(gè)像素一個(gè)字節(jié)，那么最終存儲(chǔ)的長度是132個(gè)字節(jié)，但后面的幾個(gè)字節(jié)如果不填充是未知的內(nèi)容。上面if(nDiff){后面的就是為了填充這些多余的字節(jié)。
我的一個(gè)朋友認(rèn)為這樣寫更有效一點(diǎn)：
他的分析是：如果66%的機(jī)會(huì)nDiff不是0，這個(gè)代碼效率更高。
來看一下兩種寫法的不同：
第一種寫法是：不管3721，都判斷一下；如果nDiff不為0，需要至少3個(gè)指令：判斷/減/判斷。
第二種寫法是：不判斷，先減，然后通過for循環(huán)來判斷。對(duì)于nDiff為0不為0，都是兩個(gè)指令：減/判斷。
但如果多余66%的機(jī)會(huì)(比如70%)nDiff不為0，第一種寫法需要的平均指令數(shù)為：
70%*3+30%*1 = 2.4
第二種寫法的平均指令數(shù)為：
70%*2+30%*2 = 2
可見第二種寫法的好處可以體現(xiàn)在：
1． 代碼簡潔
2． 效率更高
但我發(fā)現(xiàn)代碼中很少的機(jī)會(huì)nDiff不為0，這位老兄又立刻想到了另一種寫法：
再來看一下這種寫法的特點(diǎn)，假設(shè)30%的機(jī)會(huì)nDiff不為0：
原來寫法的指令數(shù)為：
70%*1+30%*3 = 1.6
上面寫法的指令數(shù)為：
70%*1+30%*2 = 1.3
因?yàn)榈谝淮尾恍枰袛啵划?dāng)然后面的循環(huán)都是一樣的。
從這件事情的本身我們甚至可以說是吹毛求茨，而從效率上來說這個(gè)代碼提高的并不是很多。但我想說的不是這些，而是故事說明的寫這個(gè)代碼的時(shí)候作者在想些什么，我想至少是這樣的：
1． 寫出簡潔的代碼。第二種寫法明顯簡潔。
2． 寫出最高效的代碼，即使是CPU很快的今天。如果上面的代碼在一個(gè)循環(huán)的內(nèi)部，效率高低很快就體現(xiàn)出來。
3． 深入的思考和比較。計(jì)算條件成立的概率，至少應(yīng)該對(duì)代碼在什么情況下運(yùn)行很了解。
posted on 2007-07-06 12:44 笨笨 閱讀(1981) 評(píng)論(11) 編輯 收藏 引用 所屬分類: 編碼
不講效率的話，memset(dest, 0, nDiff);也可以 恕我直言，我個(gè)人認(rèn)為在這樣的小地方求效率的提高，不如把代碼寫的更容易讓人看懂。《Unix編程藝術(shù)》中似乎有對(duì)于這種“優(yōu)化”做過探討，我比較贊成書中作者的觀點(diǎn)。 回復(fù) 更多評(píng)論
我有兩點(diǎn)想法， 一是在性能不是關(guān)鍵因素的程序中代碼的可讀性重于效率；二是代碼效率優(yōu)化應(yīng)該針對(duì)關(guān)鍵的瓶頸。 當(dāng)然， 博主的一些思路也是值得討論的 回復(fù) 更多評(píng)論
怎麼辦，一點(diǎn)點(diǎn)都看不懂~~~ 回復(fù) 更多評(píng)論
*dest = 0; dest++; 上面這兩行代碼，可以寫成 *dest++ = 0; 回復(fù) 更多評(píng)論
@SuperPlayeR 你說的很對(duì),如果不講效率代碼寫的容易懂是關(guān)鍵.但簡潔的代碼也是讓人懂的一個(gè)方面.另外實(shí)際上我在討論的時(shí)候也很關(guān)注效率的問題. 回復(fù) 更多評(píng)論
@AlanTop 很好,你的這種做法很正確. 回復(fù) 更多評(píng)論
你說的很對(duì), ------------------------------------------------- http://www.sy555.com 回復(fù) 更多評(píng)論
<p><a href="/"";http://www.qq128.net/">QQ信息網(wǎng)</a></p> 回復(fù) 更多評(píng)論
支持第二種。 回復(fù) 更多評(píng)論
why not initialize dest buffer at the beginning, such as using memset(...) ? If I am right, the size of dest buffer can be work out the beginning. ... also, the code segment like for(n ... ; n++) can be write as for(n....; ++n) .. would be better for compiler.... 回復(fù) 更多評(píng)論
@Jerry.Yu memset is high price if you just set several bytes as zero, so from performancd view, memset isn't always good. You don't understand the problem really yet. The write style just to avoid two check condition words 回復(fù) 更多評(píng)論
Powered by: C++博客 Copyright © 笨笨