结论：因为栈是4字节对齐的，因此1字节的Byte、2字节的Boolean和Integer，其实和4字节Long一样，建议大家尽可能使用4字节的Long来提高代码性能。

一、什么是栈对齐？

简单来说，栈对齐就是将栈内存空间等距划分为一个个格子。32位机器上，这个等距离为4字节。对齐是指使用栈时，起始地址必须是前述格子的首位置。也即栈是4字节对齐的。

二、为什么要对齐？

因为整齐，才方便操作，才快啊。大家知道GPU在处理浮点计算时，比CPU要快，所以装高性能显卡，可以大大提升计算机的算力。VB处理文件时，有随机文件和顺序文件之分，而随机文件远比顺序文件要快（随机文件每次操作的长度是一样的）。内存页面按4K对齐，硬盘也要分区4K对齐，诸如此类的例子，在计算机里数不胜数，都是因为整齐才快。

整齐的背后，其实跟寻址有关。计算机代码都要通过高速缓存才能被CPU执行，而这个高速缓存就是寄存器啦。在32位X86机器上，寄存器是32位的。也就是说栈按4字节对齐，实际上就是与寄存器的容量和寻址能力对齐，这样指令执行起来才不至于耗费更多的CPU时钟周期，从而提升运算性能。

三、VB变量的栈对齐表现

在前面的文章里，给大家介绍了VarPtr函数可以取变量地址，那我们正好可以使用它来看看变量在栈上的分配情况。

1、验证栈是否是4字节对齐的

如果栈不是4字节对齐的，那么4字节变量地址就一定会出现4字节不对齐的情况。我们可以试验若干次VarPtr(Lng)的返回值，其实都是4的倍数。其实这个验证更多是搞起耍的，但的确可以从现象上来印证。

2、VB中Byte、Boolean、Integer与Long的资源开销是否一致呢？

为了验证，我们写如下demo，然后编译为EXE：

可以得出以下结论：

（1）每个变量的确位于4字节对齐的位置，与变量类型无关。

（2）栈上内存分配的位置顺序与变量顺序一致。

（3）Byte、Boolean、Integer在栈上分配的内存，的确占4字节，与Long的开销一样。

是不是有点开心，但是别高兴太早，再在IDE环境中使用解释机制运行下：

可得出什么结论：

（1）Long类型位于4字节对齐位置，其他显然没有。

（2）栈上内存分配位置与变量顺序一致。

（3）资源开销，貌似跟Long一样。

是不是可以下结论了呢？为了说明情况，我们增加一些变量，并将变量顺序打乱，再看看：

说明编译机制下，前述结论是正确的，那解释机制呢？

在IDE的解释机制下，可以说明：

（1）栈内存分配的确是4字节对齐的，栈内存分配顺序与变量顺序一致，但明显有按类组合的特性，且会利用已分配内存，浪费少。

（2）Byte、Boolean、Integer在栈上的资源开销与Long不一致，比编译机制更节约资源。

四、前述结论如何理解，是否具有普遍性呢？

其实栈对齐，是由编译器及具体的优化策略决定的。VB6与VC6的Debug版本的编译器及优化策略是一致的，VB6和VBA的IDE则完全是另外一套机制。通过前面的实验，可以看出，VB的编译机制，开销更大，而解释机制则开销更小。

那究竟哪种要好点呢？尽管二者都尽量与寄存器机制保持一致，但性能上是存在区别的。根据Intel手册，从AL/AH/AX换到EAX时，会有5-6个时钟周期的延迟，因此VB的解释机制，虽然节省资源，但性能却不如编译机制。

那究竟差异好大呢？其实在编码层，尤其是在IDE环境下，是感觉不到的。更何况VB的解释器是全部用汇编写的，性能非常强悍，也就是说，二者的差异可以忽略不计。但为什么还是会觉得VB6的编译比解释快呢？解释机制感觉起来很慢，是因为要逐行翻译代码，还得随时响应暂停等人机交互。尤其是VBA代码使用Office的GUI元素，系统还要处理大量的窗口消息，当然慢啦。