[問題] 程式效率

[million31406 (我想當鄉民)]

請問各位版友

最近小弟在撰寫視窗程式搭配攝影機

原本預期每秒可以達30張frame(我開了兩個都是640*480的視窗)

但是在實作了一些演算法後 每秒的frame數變成只有15

雖然對於人眼看起來是沒差 但是總想將程式變成最佳化

我目前的做法有:

1.演算法的部分盡量使用C/C++函式庫

2.迴圈改成foreach或是parallel.foreach

3.用指標格式去access每張影像中的pixel

目前有想到可以更有效率的的是使用thread

另開一個thread去處理演算法

但是對thread還不熟也還在研究中

不知道其他版友們有什麼更高效率的作法呢?

謝謝

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 140.118.20.62
→ diabloevagto:演算法有emgu能用，或是c++的opencv
→ diabloevagto:用那些會比自己寫快非常多
→ diabloevagto:不知道用emgu或是opencv+呼叫dll
→ diabloevagto:那個會比較快
→ million31406:diablo大 我也有使用emgu 不過它有用invoke方式呼叫
→ million31406:opencv的函式 所以可能一樣吧 我猜
推 Hermite:跳frame做 thread  演算法重新看一下設計 這樣太慢了
→ Hermite:另外你可以先resize 降到320*240來做 不然loading也太重
→ Hermite:2張640*480 30FPS 如果演算法或流程不夠好 難免會掉frame
→ Hermite:不然你只能採GPU加速或者是看chip有沒有function支援
推 chchwy:先用profiler找出瓶頸在哪裡，再去針對瓶頸優化效能
→ chchwy:用人腦猜測多半都會猜錯，做了改善有限的優化。
→ million31406:h大 你說的跳frame作thread指的是每n個frame
→ million31406:透過thread執行演算法嗎?
→ million31406:ch大謝謝提供關鍵字
推 Laluth:google unsafe c# 可能有幫助
推 IKAFIRE:foreach和for比起來不會比較快，只是比較好看
→ bbcust:會比較快  樓上別亂說  不信去跑個10萬次迴圈看時間
推 IKAFIRE:樓上，因為10萬次分不出勝負，所以我加碼到了一億次
→ IKAFIRE:http://ppt.cc/zUJV
→ IKAFIRE:跑了幾次，平均約莫是for:300ms，foreach:700ms
→ IKAFIRE:還是我這測試寫得不好，請您多多指教
→ million31406:謝謝 la大 也許我的演算法可以用指標改寫
→ million31406:ik大!! 我一直以為foreach會比較快耶@@ 之前也是有
→ million31406:看到別人用數據跑是foreach比較快 可是看到你的結果
→ million31406:我矛盾了@@ why!!!
→ s3748679:給I大，幫修正: http://ideone.com/SkdJL
→ s3748679:次數為一千萬次.. Milliseconds修正為TotalMilliseconds
→ s3748679:再大我家會error
推 gundan:Millisecond是當下的毫秒時間，用totalmilliseconds才對！
推 IKAFIRE:感謝指教，沒注意到少了Total會把頭砍掉，而且StopWatch也
→ IKAFIRE:比DateTime適合測量時距，受教了
→ IKAFIRE:我用s大的內容跑起來變成兩個互有輸贏，for小勝但勝得很少
→ IKAFIRE:我對foreach的理解是：遍歷時會多一筆IEnumerator的開銷
→ IKAFIRE:所以通常速度會<=for迴圈，除非遇到linked list之類的資料
→ IKAFIRE:結構foreach才比較有效率上的優勢，這樣的理解有誤嗎?
推 s3748679:剛google後的內容，可以參考看看: http://ppt.cc/uJ9f
→ s3748679:補充一下: 我本身也不清楚.. 所以找找資料看看有無幫助
→ Litfal:不要拿效能作為選擇for或foreach的指標，只是捨本逐末
→ Litfal:若你用SetPixel來控制圖片，請優先考慮直接訪問記憶體
→ bbcust:之前我測的時候二者差異foreach比for快得有點明顯
→ bbcust:剛剛我再直接拿s3748679 source來跑
→ bbcust:還是foreach比較快  但是快得幅度很小  大概快個100ms
→ bbcust:不過這次的測試差異就很小
→ Litfal:真要提for的話，請在編譯最佳化下直接執行程式(Ctrl+F5)
→ Litfal:以你們提供的例子而言，差距應該幾乎消失了
→ Litfal:微觀的話，包含IEnumerator的實作方式，for給定的邊界條件
→ Litfal:都會影響for/foreach的效能，但大多數情況下不會是瓶頸所在
→ Litfal:例如你們用i<array.Length作for的邊界檢查
→ Litfal:你怎麼知道get Length屬性不會有效能損失？
→ Litfal:回到主題，在進行優化之前，最好先找到瓶頸在哪
→ Litfal:看你是想要用工具還是用Watch物件切塊計時，都可以
→ Litfal:但我的話，下一步會是把輸入/處理/輸出的segment分開來
→ Litfal:然後使用Pipeline模式
→ s3748679:依L大觀點來講，倒是認為在瓶頸處先看看有無機會降低
→ s3748679:時間複雜度。
→ s3748679:當然以原Po的例子，可能不是這方面的問題@@"
→ million31406:謝謝各位提出的觀點讓我受益良多 再經過這幾天的
→ million31406:survy 目前傾向於嘗試thread 把演算法丟給work
→ million31406:thread 處理 UI thread還是只擷取/顯示畫面
→ million31406:效果如何 再跟各位分享
→ million31406:litf大提出的關鍵字 pipeline我先google查資料 thx!