作者million31406 (我想當鄉民)
看板C_Sharp
標題[問題] 程式效率
時間Sat Jun 16 21:05:57 2012
請問各位版友
最近小弟在撰寫視窗程式搭配攝影機
原本預期每秒可以達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
1F：→ diabloevagto:演算法有emgu能用，或是c++的opencv 06/16 21:18
2F：→ diabloevagto:用那些會比自己寫快非常多 06/16 21:19
3F：→ diabloevagto:不知道用emgu或是opencv+呼叫dll 06/16 21:19
4F：→ diabloevagto:那個會比較快 06/16 21:19
5F：→ million31406:diablo大 我也有使用emgu 不過它有用invoke方式呼叫 06/16 21:25
6F：→ million31406:opencv的函式 所以可能一樣吧 我猜 06/16 21:25
7F：推 Hermite:跳frame做 thread 演算法重新看一下設計 這樣太慢了 06/16 22:02
8F：→ Hermite:另外你可以先resize 降到320*240來做 不然loading也太重 06/16 22:04
9F：→ Hermite:2張640*480 30FPS 如果演算法或流程不夠好 難免會掉frame 06/16 22:05
10F：→ Hermite:不然你只能採GPU加速或者是看chip有沒有function支援 06/16 22:06
11F：推 chchwy:先用profiler找出瓶頸在哪裡，再去針對瓶頸優化效能 06/16 22:41
12F：→ chchwy:用人腦猜測多半都會猜錯，做了改善有限的優化。 06/16 22:42
13F：→ million31406:h大 你說的跳frame作thread指的是每n個frame 06/16 22:51
14F：→ million31406:透過thread執行演算法嗎? 06/16 22:51
15F：→ million31406:ch大謝謝提供關鍵字 06/16 22:52
16F：推 Laluth:google unsafe c# 可能有幫助 06/17 00:35
17F：推 IKAFIRE:foreach和for比起來不會比較快，只是比較好看 06/17 02:02
18F：→ bbcust:會比較快 樓上別亂說 不信去跑個10萬次迴圈看時間 06/17 03:36
19F：推 IKAFIRE:樓上，因為10萬次分不出勝負，所以我加碼到了一億次 06/17 13:57
21F：→ IKAFIRE:跑了幾次，平均約莫是for:300ms，foreach:700ms 06/17 13:59
22F：→ IKAFIRE:還是我這測試寫得不好，請您多多指教 06/17 14:00
23F：→ million31406:謝謝 la大 也許我的演算法可以用指標改寫 06/17 16:15
24F：→ million31406:ik大!! 我一直以為foreach會比較快耶@@ 之前也是有 06/17 16:15
25F：→ million31406:看到別人用數據跑是foreach比較快 可是看到你的結果 06/17 16:16
26F：→ million31406:我矛盾了@@ why!!! 06/17 16:16
28F：→ s3748679:次數為一千萬次.. Milliseconds修正為TotalMilliseconds 06/17 19:15
29F：→ s3748679:再大我家會error 06/17 19:16
30F：推 gundan:Millisecond是當下的毫秒時間，用totalmilliseconds才對！ 06/18 01:46
31F：推 IKAFIRE:感謝指教，沒注意到少了Total會把頭砍掉，而且StopWatch也 06/18 01:56
32F：→ IKAFIRE:比DateTime適合測量時距，受教了 06/18 01:56
33F：→ IKAFIRE:我用s大的內容跑起來變成兩個互有輸贏，for小勝但勝得很少 06/18 01:58
34F：→ IKAFIRE:我對foreach的理解是：遍歷時會多一筆IEnumerator的開銷 06/18 02:08
35F：→ IKAFIRE:所以通常速度會<=for迴圈，除非遇到linked list之類的資料 06/18 02:09
36F：→ IKAFIRE:結構foreach才比較有效率上的優勢，這樣的理解有誤嗎? 06/18 02:09
38F：→ s3748679:補充一下: 我本身也不清楚.. 所以找找資料看看有無幫助 06/18 02:25
39F：→ Litfal:不要拿效能作為選擇for或foreach的指標，只是捨本逐末 06/18 14:02
40F：→ Litfal:若你用SetPixel來控制圖片，請優先考慮直接訪問記憶體 06/18 14:11
41F：→ bbcust:之前我測的時候二者差異foreach比for快得有點明顯 06/18 14:24
42F：→ bbcust:剛剛我再直接拿s3748679 source來跑 06/18 14:24
43F：→ bbcust:還是foreach比較快 但是快得幅度很小 大概快個100ms 06/18 14:25
44F：→ bbcust:不過這次的測試差異就很小 06/18 14:26
45F：→ Litfal:真要提for的話，請在編譯最佳化下直接執行程式(Ctrl+F5) 06/18 14:34
46F：→ Litfal:以你們提供的例子而言，差距應該幾乎消失了 06/18 14:34
47F：→ Litfal:微觀的話，包含IEnumerator的實作方式，for給定的邊界條件 06/18 14:37
48F：→ Litfal:都會影響for/foreach的效能，但大多數情況下不會是瓶頸所在 06/18 14:38
49F：→ Litfal:例如你們用i<array.Length作for的邊界檢查 06/18 14:40
50F：→ Litfal:你怎麼知道get Length屬性不會有效能損失？ 06/18 14:41
51F：→ Litfal:回到主題，在進行優化之前，最好先找到瓶頸在哪 06/18 14:47
52F：→ Litfal:看你是想要用工具還是用Watch物件切塊計時，都可以 06/18 14:47
53F：→ Litfal:但我的話，下一步會是把輸入/處理/輸出的segment分開來 06/18 15:04
54F：→ Litfal:然後使用Pipeline模式 06/18 15:05
55F：→ s3748679:依L大觀點來講，倒是認為在瓶頸處先看看有無機會降低 06/18 17:24
56F：→ s3748679:時間複雜度。 06/18 17:24
57F：→ s3748679:當然以原Po的例子，可能不是這方面的問題@@" 06/18 17:27
58F：→ million31406:謝謝各位提出的觀點讓我受益良多 再經過這幾天的 06/18 18:32
59F：→ million31406:survy 目前傾向於嘗試thread 把演算法丟給work 06/18 18:33
60F：→ million31406:thread 處理 UI thread還是只擷取/顯示畫面 06/18 18:33
61F：→ million31406:效果如何 再跟各位分享 06/18 18:34
62F：→ million31406:litf大提出的關鍵字 pipeline我先google查資料 thx! 06/18 18:35