Use the correct test method when optimizing code

When we want to improve the efficiency of VB, we often use tests to test the advantages and disadvantages of algorithms, but the "algorithms" of the test itself are ignored! Here I would like to say a "story ":
When I studied an Alpha operation code, I felt the same problem: he compared the VB algorithm with AlphaBlend In the API, and the result showed that VB was faster. I also wrote an Alpha operation code, so I analyzed his source code and found that there are two differences between the two,
First, he uses DIB, while I am based on DDB, so his speed is very consistent. Because I have different color-depth algorithms, the natural speed is also different, 16-bit color processing is always slower;
Second, he uses the SafeArray structure pointer, but I don't have it. One reason why I cannot use this pointer is that his DIB bitmap is pre-loaded into his own DIBSection, the Data Pointer has been obtained at the time of creation, so that an array replication process is less than that of DDB.
Pointers are not the only tricks of VB. Is it faster to use pointers than C? After looking at the test method used in the code, I realized that DIB is pre-loaded and timing is only an operation part. AlphaBlend certainly does not have this priority. Although it also uses this DIB, but it does not have its pointer. It still needs to obtain the DIB data first, then process it, and finally output it back to the DIB, and then output it to the screen uniformly by VB. This is of course slow.
In fact, processing with DIB is indeed simple, because it can unify the bitmap data format, an algorithm can adapt to all colors. But why didn't I use DIB later? The reason is that DIB is slow. The Alpha effect is a dynamic screen effect, and the original images are based on DDB, therefore, there is no ready-made DIB available in practical applications.
If DIB is used, a conversion is required. DDB is drawn into the newly created DIBSection. Don't underestimate this conversion. My test shows that a complete Alpha processing is performed in this way, the time that DDB draws to DIBSection accounts for 70% of the total processing time !!!
I was surprised by the fact that the speed of using pointer algorithms is almost the same as that of directly processing arrays without pointers. So when we look at "from DDB as the input source to re-output back to DDB" as a process, my DDB processing method is three times faster than the DIB method, but still far slower than AlphaBlend, I am even more confused about the usage of VB pointers.
Therefore, all kinds of tests must not leave the scope of practical application, otherwise they will go astray. Several Functions of BlueDog (), except the Assembly, are the same as the methods I use in processing, but I am built into the processing process, not to mention faster than function calls; the Assembly estimation is to call a function that uses C for the shift operation, just as I am disappointed with the speed of CopyMemory. As a lift function call, I do not dare to think too much about its speed.