前言
我们外面不一样,里面一样
笔者在《VB的天地,横看成岭侧成峰 》中曾以知识点的形式,给大家讲了这么一个结论:因为栈是4字节对齐的,因此1字节的Byte、2字节的Boolean和Integer,其实和4字节Long一样,建议大家尽可能使用4字节的Long来提高代码性能。然后有朋友私信我表示不服,其实前述结论是没有问题的,但没有说的很清楚。具体是怎么回事呢?接下来,就来详细盘盘栈对齐对VB变量选择的影响。
一、什么是栈对齐?
简单来说,栈对齐就是将栈内存空间等距划分为一个个格子。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:
点击看大图
运行下,看看结果:
变量顺序:abcde
可以得出以下结论:
(1)每个变量的确位于4字节对齐的位置。
(2)栈上内存分配与变量顺序一致。
(3)Byte、Boolean、Integer在栈上分配的内存,的确占4字节,与Long的开销一样。
是不是有点开心,但是别高兴太早,再在IDE环境中使用解释机制运行下:
纳尼?有情况
变量在栈内存分配情况
可得出什么结论:
(1)Long类型位于4字节对齐位置,其他显然没有。
(2)栈上内存分配与变量顺序一致。
(3)资源开销,貌似跟Long一样。
是不是可以下结论了呢?为了说明情况,我们增加1些变量,并将变量顺序打乱,再看看:
点击看大图
编译运行结果:
变量顺序为:aefcbgd
说明编译机制下,前述结论是正确的,那解释机制呢?
栈内存分布情况(变量顺序为:aefcbgd)
在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元素,系统还要处理大量的窗口消息,当然慢啦。
点击头像加关注,BtOfficer带给你更多VB底层的知识。