作者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