查看: 178  |  回复: 0
VB6 VB中Byte、Boolean和Integer与Long的开销及性能相同吗?
楼主
发表于 3月23日 23:08

结论:因为栈是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元素,系统还要处理大量的窗口消息,当然慢啦。


您需要登录后才可以回帖 登录 | 立即注册
【本版规则】请勿发表违反国家法律的内容,否则会被冻结账号和删贴。
用户名: 立即注册
密码:
2020-2024 MaNongKu.com