优化代码时要选用正确的测试方法

类别:.NET开发 点击:0 评论:0 推荐:

想提高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字节以上,还是值得调用一下函数的。

本文地址:http://com.8s8s.com/it/it41300.htm