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

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