PTT數位生活區 / C_Sharp (C#)

[問題] 程式效率

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