Choose the correct test method when optimizing the code

Optimization
In order to improve the efficiency of VB, commonly used tests to check the pros and cons of the algorithm, but the test itself "algorithm" is ignored! Here I would like to say a "story":
When I look at the code for Alpha, I feel the same thing: he compares the VB algorithm with the AlphaBlend in the API, and the results show that VB is faster. Because I have also written an Alpha operation code, so the analysis of his source code, found that there are two different,
One is that he is using DIB, and my is based on DDB, so his speed is very consistent, and my due to different color depth algorithm, natural speed is different, 16-bit color processing is always slow;
The second is that he uses the SAFEARRAY structure pointer, and I don't, one reason I can't use this pointer is that his DIB bitmap is preloaded into the dibsection that he created and gets the data pointer when it is created, which makes it less of a one-step array copy process than DDB.

The pointer is not a unique skill of VB, is it, using the pointer will be faster than C? And then I looked at the test method for that piece of code, I understand: DIB is preloaded, timing is only an operational part, AlphaBlend of course does not have this priority, although it is also using this DIB, but it does not have its pointer, it still need to obtain this DIB data, and then processing, Finally output back to this Dib, and then by VB Unified output to the screen, which of course slow.

In fact, using DIB processing is really simple, because you can unify the bitmap data format, an algorithm can adapt to all color depth. But why did I not use Dib later, the reason is a bit: Dib slow ah, alpha effect is a dynamic screen, the original image is based on DDB, so the actual application is not a ready-made DIB available.
If you are using DIB, you must have a conversion to draw DDB into the newly created dibsection, and don't underestimate this one, I test that this is the way to perform a complete alpha processing, and the time that DDB draws into dibsection takes up the entire processing time 70%!!!

Another surprise to me was that the arithmetic part was timed separately, and I found that the pointer algorithm was almost the same as the speed with which I didn't use the pointer to handle the array directly. So when the "from DDB to the input source, to the return of DDB" as a process to see looks down, my DDB method is faster than the DIB 3 times times more, but still far slower than alphablend, I am more confused with the use of VB pointer.

So all kinds of tests must not leave the actual application of this range, otherwise it will go astray. Several functions of BlueDog (), except for that assembly, it is the same as the method I use in processing, but I am placed inside the process, needless to say certainly faster than the function call; The assembly is supposed to call a function that uses C to do shift operations, just as I am disappointed with copymemory speed, As a function call, I do not dare to hold too much illusion about its speed.

Based on the results of my repeated tests, I've been trying to come up with a surprising conclusion: CopyMemory sometimes does not use loops to take values directly from an array!

Previously thought it fast conclusion is derived from the test conditions of misunderstanding, in our testing, the different algorithms are always in the debugging environment first to compare, in the debugging environment with CopyMemory instead of using a loop from the array value, will make the speed significantly improved, why? Because CopyMemory is a function that has already been compiled! If the loop is compiled by native code, it will be faster than calling the function CopyMemory. Because it eliminates the overhead of function calls under the same execution mode.

However, copymemory in the data increase when the speed drop is not obvious, and the cycle is weak, so large data or suggest to use copymemory, this length is not OK, by testing conditions, generally more than 32 bytes, or it is worth calling the function.