[問題] if所增加的處理時間

作者tylpk (tylpk)

看板Programming

標題[問題] if所增加的處理時間

時間Thu Jan 25 23:39:24 2007

程式寫久了有一些疑問雖然我們都知道很多時候 if else擺在什麼地方迴圈內或迴圈外實際上會造成不同的結果但我納悶的是現今的硬體下在一定數量的範圍之內會有比較明顯的感覺變慢嗎？我會這樣問的原因是我有約1萬筆的資料要解析他的格式並擷取所需資料組成另一種格式的檔案並存檔原本程式縮需時間約22分鐘今天在看Spec時發現某些資料必須判斷是不是偶數的長度若不是需在資料後面補一個\0 但我發現當我補上 if( (inValueLength%2) != 0) { //Dosomething } 所需時間增加為26分鐘等於多跑1萬個if居然會造成時間增加 19% 雖然我知道這樣的測試結果不能代表什麼但還是覺得很困惑兩天的環境都是只開ultraedit寫程式有一個防毒常駐在角落雖然一個是早上測試一個是下午測試但大概可以忽略環境的影響難道真的是因為現在的硬體還不夠快到可以浪費在這種if else的判斷還是說%真的比較耗CPU指令去做事(要用bit運算去判斷？) 不知道有沒有人可以解答我疑惑感謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 125.232.215.202

推 StubbornLin:你應該另外寫程式去跑for if %那些 59.116.78.242 01/25 23:56

→ StubbornLin:簡單的就好才能比較準確地知道 59.116.78.242 01/25 23:57

→ StubbornLin:if和%的影響有多少 59.116.78.242 01/25 23:57

→ StubbornLin:我個人認為應該是沒那麼誇張 59.116.78.242 01/25 23:57

→ StubbornLin:通常會慢主要跟IO有關係 59.116.78.242 01/25 23:58

→ StubbornLin:還有求是不是偶數可以用&去做 59.116.78.242 01/25 23:58

→ StubbornLin:%骨子裡應該是除法而除法很慢 59.116.78.242 01/25 23:59

→ StubbornLin:用bit運算應該是會比較快沒錯 59.116.78.242 01/25 23:59

推 avhacker:前兩天才看到同事報告的，以pentium4為例 140.123.19.235 01/26 00:38

→ avhacker:%要23個clock cycle, - 則只要 0.5 cycle 140.123.19.235 01/26 00:39

→ avhacker:用 & 跟用 - 我耗用的 cycle應該是一樣的 140.123.19.235 01/26 00:39

推 SILee:我有一個疑問一般這種情形compiler在編譯 61.59.105.115 01/26 01:11

→ SILee:時不是會自動去重新整理code作optimize嗎? 61.59.105.115 01/26 01:12

→ SILee:除非程式真的太凌亂了超出compiler的能力 61.59.105.115 01/26 01:13

→ SILee:不然應該影響不大吧 61.59.105.115 01/26 01:14

推 pakker:a%2 和 a&0x1 雖然意義一樣但compiler懂嗎? 61.224.77.107 01/26 08:06

推 jtmh:gcc v3.4.2 未開最佳化就已經是用 & 來算了 218.175.160.9 01/26 13:53

推 s88:for..if..else跟處理器的brach prediction... 140.123.103.46 01/26 16:32

→ s88:如果你的for loop裡面有loop inviriant... 140.123.103.46 01/26 16:33

推 AppleFox:我猜是DoSomething那邊有I/O處理 XD 218.166.157.13 01/26 19:14

推 meltice:隨便移動滑鼠就幾百次interrupt 218.211.11.246 01/26 23:04

→ meltice:Windows就要處裡這些中斷好忙啊 218.211.11.246 01/26 23:05

推 walking:以現在的CPU,十萬次 if,% 都不用一秒. 219.80.128.184 01/28 13:24