优化代码时要选用正确的测试方法
2005-04-12 19:56
465 查看
想提高VB效率的时候,常用测试来检验算法的优劣,但测试本身的“算法”却被忽略!这里我很想说一段“故事”:
我在研究一个Alpha运算的代码时,就感到了同样的问题:他把VB算法与API中的AlphaBlend做了比较,结果证明VB更快。因为我也写过一个Alpha运算的代码,所以针对他的源码做了分析,发现二者有两个不同,
一是他使用的是了DIB,而我的是基于DDB,所以他的速度很一致,而我的因涉及不同色深算法不同,自然速度也不一样,16位色处理始终慢些;
二是他使用了SafeArray结构指针,而我没有,我无法用这种指针的一个原因是,他的DIB位图是预先载入自己创建的DIBSection的,创建时便已获取了数据指针,这样就会比DDB少了一步数组复制过程。
指针并不是VB的独门绝技,难道,用了指针就会比C快?再看了一下那段代码用的测试方法,我才明白:DIB是预先载入的,计时的只是一个运算部分,AlphaBlend当然没有这个优先权,它虽然也是用这个DIB,但它没有其指针,它仍需先获取这个DIB数据,再处理,最后再输出回这个DIB,再由VB统一输出到屏幕,这当然慢。
其实用DIB处理的确简单,因为可以统一位图数据格式,一个算法便能适应所有色深。但我为什么后来没用DIB,原因就是一点:DIB慢呀,Alpha效果是一种屏幕动态效果,原始图都是基于DDB的,所以实际应用中是不会有现成的DIB可用的。
若使用DIB,必需得有一次转换,将DDB绘入新创建的DIBSection,别小看了这一次转换,我测试表明,用这种方式进行一次完整的Alpha处理,DDB绘入DIBSection的时间占整个处理时间的70%!!!
另一个让我大为吃惊的是,单独对运算部分计时,我发现用指针的算法,与我不用指针直接处理数组速度几乎一样。所以当把“从DDB做输入源,到重新输出回DDB”做为一个过程来看待时,我的DDB处理法比DIB法快了3倍多,但仍远慢于AlphaBlend,我对VB的指针用法更开始茫然。
所以各种测试一定不要离开实际应用这个范围,不然真会走入歧途。BlueDog() 的几个函数,除那个汇编外,与我在处理中使用的方法都一样,但我是内置于处理过程中的,不用说肯定比函数调用要快;汇编那段估计是调用一个利用C做移位运算的函数,就象我对CopyMemory速度都感到失望一样,做为一次函数调用,我对其速度也不敢抱太多幻想。
根据我反复测试的结果,我一直想推出一个让很多人大跌眼镜的结论:CopyMemory有时还没有用循环从数组直接取值快!
以前认为它快的结论是源于对测试条件的误解,在我们测试时,换有不同算法总是在调试环境下先进行比较的,在调试环境下用CopyMemory代替用循环从数组取值,会使速度明显提高,为什么?因为CopyMemory是已经过编译的函数!若循环也经过本机码编译,其就会比调用函数CopyMemory快了。因为它在同等执行方式下,省去了函数调用的开销。
不过CopyMemory在数据增大时速度下降不明显,而循环这方面就弱了,所以大数据还是建议用CopyMemory的,这个长度不好确定,由测试情况决定,一般32字节以上,还是值得调用一下函数的。
我在研究一个Alpha运算的代码时,就感到了同样的问题:他把VB算法与API中的AlphaBlend做了比较,结果证明VB更快。因为我也写过一个Alpha运算的代码,所以针对他的源码做了分析,发现二者有两个不同,
一是他使用的是了DIB,而我的是基于DDB,所以他的速度很一致,而我的因涉及不同色深算法不同,自然速度也不一样,16位色处理始终慢些;
二是他使用了SafeArray结构指针,而我没有,我无法用这种指针的一个原因是,他的DIB位图是预先载入自己创建的DIBSection的,创建时便已获取了数据指针,这样就会比DDB少了一步数组复制过程。
指针并不是VB的独门绝技,难道,用了指针就会比C快?再看了一下那段代码用的测试方法,我才明白:DIB是预先载入的,计时的只是一个运算部分,AlphaBlend当然没有这个优先权,它虽然也是用这个DIB,但它没有其指针,它仍需先获取这个DIB数据,再处理,最后再输出回这个DIB,再由VB统一输出到屏幕,这当然慢。
其实用DIB处理的确简单,因为可以统一位图数据格式,一个算法便能适应所有色深。但我为什么后来没用DIB,原因就是一点:DIB慢呀,Alpha效果是一种屏幕动态效果,原始图都是基于DDB的,所以实际应用中是不会有现成的DIB可用的。
若使用DIB,必需得有一次转换,将DDB绘入新创建的DIBSection,别小看了这一次转换,我测试表明,用这种方式进行一次完整的Alpha处理,DDB绘入DIBSection的时间占整个处理时间的70%!!!
另一个让我大为吃惊的是,单独对运算部分计时,我发现用指针的算法,与我不用指针直接处理数组速度几乎一样。所以当把“从DDB做输入源,到重新输出回DDB”做为一个过程来看待时,我的DDB处理法比DIB法快了3倍多,但仍远慢于AlphaBlend,我对VB的指针用法更开始茫然。
所以各种测试一定不要离开实际应用这个范围,不然真会走入歧途。BlueDog() 的几个函数,除那个汇编外,与我在处理中使用的方法都一样,但我是内置于处理过程中的,不用说肯定比函数调用要快;汇编那段估计是调用一个利用C做移位运算的函数,就象我对CopyMemory速度都感到失望一样,做为一次函数调用,我对其速度也不敢抱太多幻想。
根据我反复测试的结果,我一直想推出一个让很多人大跌眼镜的结论:CopyMemory有时还没有用循环从数组直接取值快!
以前认为它快的结论是源于对测试条件的误解,在我们测试时,换有不同算法总是在调试环境下先进行比较的,在调试环境下用CopyMemory代替用循环从数组取值,会使速度明显提高,为什么?因为CopyMemory是已经过编译的函数!若循环也经过本机码编译,其就会比调用函数CopyMemory快了。因为它在同等执行方式下,省去了函数调用的开销。
不过CopyMemory在数据增大时速度下降不明显,而循环这方面就弱了,所以大数据还是建议用CopyMemory的,这个长度不好确定,由测试情况决定,一般32字节以上,还是值得调用一下函数的。
相关文章推荐
- 1 开发一个注重性能的JDBC应用程序不是一件容易的事. 当你的代码运行很慢的时候JDBC驱动程序并不会抛出异常告诉你。 本系列的性能提示将为改善JDBC应用程序的性能介绍一些基本的指导原则,这其中的原则已经被许多现有的JDBC应用程序编译运行并验证过。 这些指导原则包括: 正确的使用数据库MetaData方法 只获取需要的数据 选用最佳性能的功能 管理连
- SVN的代码正确提交方法
- ffmpeg neon优化必看!!android下编译ffmpeg with neon的正确方法(已验证)
- 实用的代码优化方法
- Java代码优化--尽可能地使用stack(栈)变量(方法内部的局部变量)
- Java代码优化--尽可能地使用stack(栈)变量(方法内部的局部变量)
- 调试优化代码方法
- 快速检验NRV优化测试代码
- Spring+SpringMVC+MyBatis+easyUI整合优化篇(三)代码测试
- 代码运行效率的简单测试(编译器,反射,优化后的反射)
- 客户端代码优化的20个方法
- 【Java并发编程】之三:线程挂起、恢复与终止的正确方法(含代码)(r)
- javascript代码加载优化方法
- 使用 Jtest:一款优秀的 Java 代码优化和测试工具
- C++代码优化方法总结
- Asp.Net异常:"由于代码已经过优化或者本机框架位于调用堆栈之上,无法计算表达式的值"的解决方法
- 【代码优化】调用optional delegates的最佳方法
- Java代码优化-在某种情况下避免Map的containsKey方法的使用
- C++代码优化方法总结
- C++代码优化方法总结