青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

隨筆 - 11, 文章 - 0, 評論 - 58, 引用 - 0
數(shù)據加載中……

i++, ++i 和i=i+1究竟哪個快?

i++, ++i 和i=i+1究竟哪個快?

引子

以前學習C++時,被告知i++的速度要比i=+1快,而++i的速度又要比i++快。即在效率上有:++i > i++ > i=i+1。所以如果單單只是需要進行遞增時,用++i是最好的。但是某天我突然覺得:這三個運算的目的都是一樣,開銷按道理應該相同才對。難道編譯器如此之笨?就連這點優(yōu)化都不會做?

運行時間測試(VS2008)

先用c#做了一遍:

static private void Test()

{

int counter = 0;

Stopwatch timer = new Stopwatch();

 

timer.Start();

for (int i = 0; i < 2147483647; i++)

{

counter++;

}

timer.Stop();

Console.WriteLine("i++: " + timer.ElapsedMilliseconds);

 

timer.Reset();

counter=0;

timer.Start();

for (int i = 0; i < 2147483647; ++i)

{

++counter;

}

timer.Stop();

Console.WriteLine("++i: " + timer.ElapsedMilliseconds);

 

timer.Reset();

counter=0;

timer.Start();

for (int i = 0; i < 2147483647; i = i + 1)

{

counter=counter+1;

}

timer.Stop();

Console.WriteLine("i=i+1: "+timer.ElapsedMilliseconds);

 

Console.WriteLine();

 

}

從結果來看,幾乎沒有分別,每個算式都有機會獲得第一名。所以我覺得這3個算式對編譯器來說應該是沒有分別的。

用c++做了一遍

void test()

{

    int elapTicks;

    double elapMilli;

    clock_t Begin, End;

    int counter = 0;

 

 

    Begin = clock() * CLK_TCK; //start the timer

    for(int i=0; i<2147483647; i++) counter++;

    End = clock() * CLK_TCK; //stop the timer

 

    elapTicks = End - Begin; //the number of ticks from Begin to End

    elapMilli = elapTicks/1000; //milliseconds from Begin to End

    cout<<"i++: "<<elapMilli<<"\n";

 

    counter=0;

    Begin = clock() * CLK_TCK; //start the timer

    for(int i=0; i<2147483647; ++i) ++counter;

    End = clock() * CLK_TCK; //stop the timer

 

    elapTicks = End - Begin; //the number of ticks from Begin to End

    elapMilli = elapTicks/1000; //milliseconds from Begin to End

    cout<<"++i: "<<elapMilli<<"\n";

 

    counter=0;

    Begin = clock() * CLK_TCK; //start the timer

    for(int i=0; i<2147483647; i=i+1)counter=counter+1;

    End = clock() * CLK_TCK; //stop the timer

 

    elapTicks = End - Begin; //the number of ticks from Begin to End

    elapMilli = elapTicks/1000; //milliseconds from Begin to End

    cout<<"i=i+1: "<<elapMilli<<"\n\n";

 

}

結果也是類似。

結論

i++, ++i 和i=i+1的區(qū)別,應該只是純粹理論上的區(qū)別(即按照相應的表達算式進行編譯)。個人猜測對于以上3個表達式,編譯器在編譯之后應該生成一樣的語句。不過我不懂匯編,也不懂如何進一步深入測試。就此次測試的結果來看,3個表達式的時間開銷是一樣的(每次運行結果誤差應該是其他原因)。當然,此分析僅限于VS2008,有可能這3個語句在其他編譯器上的性能會有所不同。

歡迎指正。

posted on 2010-07-14 13:41 54sun 閱讀(10434) 評論(29)  編輯 收藏 引用 所屬分類: 隨筆

評論

# re:   回復  更多評論   

明顯++i
2010-07-14 14:00 | wangfan1985@gmail.com

# re:   回復  更多評論   

編譯器不會那么笨的,我自己寫的那個都能發(fā)現(xiàn)他們三個是一樣的。
2010-07-14 14:18 | 陳梓瀚(vczh)

# re:   回復  更多評論   

@wangfan1985@gmail.com
那是你用的編譯器過于爛,或者你沒有打開應有的優(yōu)化選項,導致的。
2010-07-14 14:19 | 陳梓瀚(vczh)

# re: [未登錄]  回復  更多評論   

這么測試是不對的,應該直接看匯編
2010-07-14 14:23 | cyantree

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

# re: i++, ++i 和i=i+1究竟哪個快? 回復 更多評論 刪除評論
因為C++可以重載操作符。
所以, 除非"知道i的類型", 表達式 i++, ++i, i=i+1 的行為"未知"。

從語意上說,所需要的操作: ++i < i++ (多一個復制), i=i+1(多一個賦值)。
所以: "如果只需要++i, 就不要寫成i++; 如果只需要i++, 就不要寫成i=i+1"。
養(yǎng)成這種習慣, 無論i是什么類型都無所謂。

另一方面, 在已知i是int的情況下,如果某編譯器生成的代碼有顯著區(qū)別, 那可以把它丟了……
2010-07-14 14:16 | OwnWaterloo
2010-07-14 14:34 | 54sun

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

對這3種情況分別反匯編以后都得到以下結果
00401004 |. C745 FC 00000>mov dword ptr [ebp-4], 0
0040100B |. EB 09 jmp short 00401016
0040100D |> 8B45 FC /mov eax, dword ptr [ebp-4]
00401010 |. 83C0 01 |add eax, 1
00401013 |. 8945 FC |mov dword ptr [ebp-4], eax
00401016 |> 817D FC E8030> cmp dword ptr [ebp-4], 3E8
0040101D |. 7D 02 |jge short 00401021
0040101F |.^ EB EC \jmp short 0040100D

所以說優(yōu)化后的效率是一樣的
2010-07-14 14:42 | lwch

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

搞個 ++ 對象試一試。
區(qū)別很大
看看STL的源碼就清楚了
2010-07-14 18:27 | haven

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

樓主不厚道啊,你把明顯能優(yōu)化成一樣的代碼放在一起當然編譯器沒有那么笨,效率肯定是一樣的
你試試這樣
j = i;
i = i + 1;

i = i + 1;
j = i;

j = i ++

j = ++ i

理論上 j = i ++ 可能會慢一些,看情況,因為要先保存 i 的值,然后計算,然后將舊值賦值給 j ,其他的應該效率理論上應該是相同的
2010-07-14 18:59 | 樓主不厚道

# re: i++, ++i 和i=i+1究竟哪個快?[未登錄]  回復  更多評論   

純primitive type區(qū)別并不是太大, 用object和重載的運算符就能看出區(qū)別來了.
2010-07-14 22:59 | R

# re: i++, ++i 和i=i+1究竟哪個快?[未登錄]  回復  更多評論   

應該看看生成的匯編代碼
2010-07-15 00:51 | frank

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

對于內置類型,差別不大。對于自定義類型(class type)差別就出來啦。
自己寫個copy操作比較費時的class試試看,比如class有20000個元素的string數(shù)組,這樣后置操作符的需要多做一份拷貝的cost就出來了。
2010-07-15 00:58 | kirby

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

不知道 如果是對象調用的話 差別大不大。
編譯器會不會優(yōu)化。
2010-07-15 01:13 | 欣萌

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

不懂匯編?

那么請你用更加精確的計時手段!
2010-07-15 01:31 | coolypf

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

其實,編譯器一般都會把i++,++i,i=i+1,優(yōu)化成匯編,inc eax,,
至于你的測試,我估計是在程序運行過程中,系統(tǒng)的調度所產生的偏差(因為某段代碼用完了他的時間片,系統(tǒng)切換其它工作線程),或其它未知原因:),
因為他們所對應的指令是一樣的.
2010-07-15 01:36 | luoqi

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

。。。無語,有缺陷的測試得到的必然是有缺陷的結果,包括你代碼得到的反匯編
2010-07-15 02:11 | 。。。

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

# re: i++, ++i 和i=i+1究竟哪個快? 回復 更多評論
其實,編譯器一般都會把i++,++i,i=i+1,優(yōu)化成匯編,inc eax,,
至于你的測試,我估計是在程序運行過程中,系統(tǒng)的調度所產生的偏差(因為某段代碼用完了他的時間片,系統(tǒng)切換其它工作線程),或其它未知原因:),
因為他們所對應的指令是一樣的.


那么,你認為
j = ++ i
怎么優(yōu)化成匯編,inc eax,呢?
2010-07-15 02:14 | 。。。

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

# re: i++, ++i 和i=i+1究竟哪個快? 回復 更多評論
# re: i++, ++i 和i=i+1究竟哪個快? 回復 更多評論 刪除評論
因為C++可以重載操作符。
所以, 除非"知道i的類型", 表達式 i++, ++i, i=i+1 的行為"未知"。

從語意上說,所需要的操作: ++i < i++ (多一個復制), i=i+1(多一個賦值)。
所以: "如果只需要++i, 就不要寫成i++; 如果只需要i++, 就不要寫成i=i+1"。
養(yǎng)成這種習慣, 無論i是什么類型都無所謂。

另一方面, 在已知i是int的情況下,如果某編譯器生成的代碼有顯著區(qū)別, 那可以把它丟了……
2010-07-14 14:16 | OwnWaterloo
2010-07-14 14:34 | 54sun


這是正解。
2010-07-15 02:20 | 老安

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

@haven
對象的兩個++根本就是不同的函數(shù),沒有可比性。
2010-07-15 02:53 | 陳梓瀚(vczh)

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

@樓主不厚道
對了,我假設 i 是基本類型,
暫時先不考慮 i 是非基本類型的情況,因為那種情況 i++; ++i; i + 1; 肯定根據自己的定義了,所以顯然的問題暫不考慮
2010-07-15 02:58 | 樓主不厚道

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

各有各的用處~~
2010-07-15 03:21 | 日光博客

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

你這個測試,估計大部分的測試時間被for占去了吧
2010-07-15 08:09 | freebug

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

i是int下,都一樣。


這個之所以分這么細,完全是C++里重載 operator ++ 的緣故,自定義類型的這兩個操作,差別挺大的,i++ 需要比++i額外產生一個新對象,并返回該新對象。
2010-07-15 09:23 | www

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

這么多回復,已經很明了了,

j = ++ i

這句就可以看出來,++i和i++效率不同,
++i直接把i改變,然后值給j就可以
i++要先保存i的值,然后把i改變,再把i給j

還有什么好爭的

如果有人非說編譯器優(yōu)化,i++可以先把值給j,然后改變i,跟++i一樣,
那就再考慮 j= j + i++ 吧


回復別人問題麻煩先仔細看上面其他人回復的內容,不要想當然
2010-07-15 12:00 | 。。。

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

@樓主不厚道
其實做這個測試的目的僅僅是想知道在只需要把i遞增1的情況下,這三個算式是否有區(qū)別。比如在for語句for (int i = 0; i < 10; i=i+1),如果是c,那么i=i+1是個常用的,到了c++一般都用i++。就個人來說,我覺得i++這個形式就反映了其語言本身的名字,所以看起來很合適。但有人認為++i更效率,于是寫成for (int i = 0; i < 10;++i)。并不是說這樣有問題,只是我個人認為i++比++i要看起來自然些。更何況,其實這里++i并沒有比i++快。

此文并不是要討論運算符重載。

@OwnWaterloo
所以: "如果只需要++i, 就不要寫成i++; 如果只需要i++, 就不要寫成i=i+1"。
養(yǎng)成這種習慣, 無論i是什么類型都無所謂。

我想說的是,如果只是一個int遞增,我會用i++。形式上比較美,而且效率和++i一樣。特別是在for語句里面。(當然,你對3者區(qū)別的解釋是十分簡單明了正確的)
2010-07-15 20:54 | 54sun

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

不要用編譯器內置的數(shù)據類型測試,這樣測試看不出什么的,表明上一樣,其實是有區(qū)別的。換成自定義的數(shù)據類型,這樣的測試結果更客觀些。
2010-07-20 00:22 | Benjamin

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   


++i 中的 ++ 不一定是 i 的成員函數(shù), 嗯
2010-07-21 17:15 | Soli

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

理論上來說, ++i可能會更快, 只要一條匯編指令inc就可以了. 當然i++同樣也是.
當然這個也跟編譯器優(yōu)化有關, 且也難保證都會優(yōu)化.
2010-07-25 01:14 | programmer huang

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

貌似能證明c++速度快。。。
其實最好的辦法是看底層代碼,c#看IL,c++看匯編(用ida吧)。
同種語言對比,如果編譯的一樣,那就說明沒區(qū)別。(也許匯編不同,但實質一樣)

我覺得i++和++i的效率區(qū)別應該在是否對左值賦值的問題上,
int a=i++;

int a=++i;
不過只是猜測,一般我喜歡i++,看起來好看。不太喜歡寫復雜的表達式,寧愿分開寫,多加括號。
2011-02-14 17:19 | idreamer

# re: i++, ++i 和i=i+1究竟哪個快?  回復  更多評論   

你這測試不對
2011-04-27 08:20 | KA ZHA FEI
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            一本到高清视频免费精品| 国产精品乱人伦中文| 亚洲国产成人精品久久| 欧美jizz19性欧美| 欧美xart系列高清| 一区二区三区**美女毛片| 亚洲三级影院| 久久xxxx精品视频| 欧美91大片| 欧美精品九九| 欧美一区在线看| 久久综合久久综合久久综合| 亚洲精品乱码久久久久久日本蜜臀 | 亚洲精品在线视频观看| 国产精品成人一区| 久久午夜视频| 欧美精品在线观看播放| 亚洲欧美美女| 卡通动漫国产精品| 亚洲天堂偷拍| 久久人人爽人人| 亚洲一区二区三区四区五区黄| 欧美一区二区三区视频免费播放| 亚洲黄一区二区| 亚洲一区视频在线| 亚洲人成网站在线播| 亚洲色图制服丝袜| 亚洲精品九九| 欧美一区二区三区日韩视频| 9久re热视频在线精品| 久久av一区二区三区漫画| 夜夜嗨av一区二区三区| 久久久免费av| 久久国产精品亚洲va麻豆| 欧美大片网址| 免费成人网www| 国产美女搞久久| 亚洲乱码久久| 亚洲精选成人| 久久综合九色综合欧美狠狠| 性做久久久久久免费观看欧美| 欧美激情在线播放| 欧美成人午夜77777| 国产欧美在线观看一区| 在线亚洲观看| 在线亚洲欧美| 欧美激情一区二区三区在线| 狼人社综合社区| 狠狠色狠色综合曰曰| 午夜精品视频在线观看一区二区| 亚洲网站啪啪| 欧美色区777第一页| 亚洲高清一区二| 亚洲国内自拍| 你懂的视频欧美| 欧美承认网站| 91久久精品国产91久久性色| 久久久久女教师免费一区| 久久精品五月婷婷| 国产午夜精品理论片a级探花| 亚洲视频欧美在线| 欧美一区网站| 韩日成人av| 久久久亚洲精品一区二区三区| 久久久久**毛片大全| 国产欧美在线| 久久精品亚洲一区二区| 免费不卡在线视频| 91久久精品www人人做人人爽| 美女黄色成人网| 亚洲精品久久嫩草网站秘色| 亚洲美女在线一区| 欧美色图首页| 亚洲少妇一区| 久热这里只精品99re8久| 欧美www视频| 日韩一级大片| 国产精品久久久久久久久久久久久| 一区二区欧美在线观看| 久久爱另类一区二区小说| 国产主播精品| 欧美国产日韩一二三区| 99国产精品久久久久久久久久 | 国产农村妇女精品一区二区| 欧美亚洲免费在线| 欧美成人性生活| 一本色道久久综合亚洲精品高清| 国产精品国产一区二区| 欧美一区中文字幕| 亚洲欧洲偷拍精品| 久久riav二区三区| 亚洲黄色性网站| 国产精品毛片大码女人| 久久久亚洲一区| 亚洲一区二区欧美| 欧美成人免费观看| 亚洲愉拍自拍另类高清精品| 国内精品99| 欧美性开放视频| 老司机午夜精品视频在线观看| 亚洲精品免费在线播放| 久久久久久夜| 亚洲一区二区av电影| 在线播放国产一区中文字幕剧情欧美| 欧美大片在线观看一区二区| 亚洲在线视频| 亚洲乱码久久| 欧美成年人视频| 欧美一区二区三区喷汁尤物| 亚洲精品久久久久中文字幕欢迎你| 国产精品免费aⅴ片在线观看| 麻豆精品国产91久久久久久| 亚洲一区三区在线观看| 亚洲精品在线视频观看| 欧美a级理论片| 久久久久久欧美| 小处雏高清一区二区三区| 日韩视频中文字幕| 亚洲国产欧美日韩另类综合| 国产综合在线视频| 国产精品午夜春色av| 欧美视频中文字幕| 欧美理论在线| 欧美国产另类| 免费在线国产精品| 久久爱另类一区二区小说| 亚洲一线二线三线久久久| 亚洲精品乱码视频| 亚洲日本免费| 亚洲精品欧美一区二区三区| 欧美福利视频网站| 欧美大香线蕉线伊人久久国产精品| 久久久久久网站| 久久成人久久爱| 久久精品国产久精国产爱| 欧美一区精品| 久久久久国产精品一区三寸 | 又紧又大又爽精品一区二区| 国产日韩欧美综合一区| 国产日韩精品在线观看| 国产精品系列在线播放| 国产欧美日韩麻豆91| 国产精品日韩精品欧美在线| 国产精品视频区| 国产欧美精品国产国产专区| 国产欧美不卡| 黑丝一区二区三区| 欧美精品成人91久久久久久久| 亚洲欧洲三级| 99精品热视频| 亚洲伊人网站| 欧美一级免费视频| 久久久人成影片一区二区三区 | 夜夜嗨av一区二区三区网站四季av | 午夜精品久久久久久久99热浪潮 | 麻豆成人91精品二区三区| 久久躁狠狠躁夜夜爽| 欧美88av| 欧美三级日本三级少妇99| 国产精品免费在线| 国产一区视频在线看| 亚洲国产综合在线看不卡| 一区二区高清| 久久精品日产第一区二区| 久久美女性网| 亚洲人成网在线播放| 亚洲午夜在线观看| 久久亚洲一区| 欧美系列一区| 在线不卡亚洲| 亚洲综合999| 欧美成人日本| 亚洲欧洲av一区二区三区久久| 久久久久久一区二区| 欧美午夜免费影院| 在线精品亚洲| 亚洲欧美日韩精品久久亚洲区 | 欧美精品一区二区三区四区| 国产精品青草综合久久久久99| 黄色成人在线观看| 亚洲性视频网址| 另类av导航| 一区二区三区久久久| 欧美专区一区二区三区| 欧美日韩网站| 亚洲国产精品一区二区久 | 亚洲毛片网站| 久久综合久久美利坚合众国| 日韩午夜在线视频| 久久全国免费视频| 国产日韩精品久久| 中文av一区二区| 欧美高清一区二区| 欧美在线观看你懂的| 国产精品国产自产拍高清av王其| 亚洲国产毛片完整版 | 午夜精品电影| 亚洲精品一二三区| 美女成人午夜| 亚洲国产日韩欧美在线99|