ExcelHome技术论坛

 找回密码
 免费注册

QQ登录

只需一步,快速开始

快捷登录

搜索
EH技术汇-专业的职场技能充电站 妙哉!函数段子手趣味讲函数 Excel服务器-会Excel,做管理系统 效率神器,一键搞定繁琐工作
HR薪酬管理数字化实战 Excel 2021函数公式学习大典 Excel数据透视表实战秘技 打造核心竞争力的职场宝典
让更多数据处理,一键完成 数据工作者的案头书 免费直播课集锦 ExcelHome出品 - VBA代码宝免费下载
用ChatGPT与VBA一键搞定Excel WPS表格从入门到精通 Excel VBA经典代码实践指南
楼主: 灰袍法师

[分享] 用VB编译一模一样的VBA代码,速度马上快五倍。

[复制链接]

TA的精华主题

TA的得分主题

发表于 2011-6-2 15:25 | 显示全部楼层
本帖已被收录到知识树中,索引项:排序
VBA编译器可以想象它是APPLICATION下的一个类,或者一个子类,结构就象13楼所说的,那自然就要慢了。如果不用递归,比如用冒泡,估计VB生成EXE和VBA两者的差别就不会那么大。手头VB卸下,没法试试。

TA的精华主题

TA的得分主题

 楼主| 发表于 2011-6-2 15:27 | 显示全部楼层
我编译了最简单的语句
dim i as long, j as long
for i=1 to 10000000
  j=j+1
next

VB编译后的程序仍然比VBA快5-6倍

而VBA语句又比Ruby快8倍

所以 同样的数值计算,VB编译比Ruby快40倍以上,结论:大量数值计算型的程序,绝对不宜用Ruby。

这个数倍的速度差异,倒支持你的看法,VBA像是要调用一个方法才能执行每一句。

但是另一方面, j = j + 1这样最简单的语句,在机器语言的层面,也确实有多种实现方法,而各种方法的速度相差几倍到十几倍不等。

[ 本帖最后由 灰袍法师 于 2011-6-2 15:42 编辑 ]

TA的精华主题

TA的得分主题

发表于 2011-6-2 15:32 | 显示全部楼层
原帖由 灰袍法师 于 2011-6-2 15:27 发表
我编译了最简单的语句
dim i as long, j as long
for i=1 to 10000000
  j=j+1
next

VB编译后的程序仍然比VBA快5-6倍

而VBA语句又比Ruby快8倍

所以 同样的数值计算,VB编译比Ruby快40倍以上,结论:大 ...

这个时间太少,看不出问题。放大20-30倍试试才差不多。

TA的精华主题

TA的得分主题

 楼主| 发表于 2011-6-2 20:57 | 显示全部楼层
原帖由 Zamyi 于 2011-6-2 15:32 发表

这个时间太少,看不出问题。放大20-30倍试试才差不多。


的确应该是 生成的指令的效率问题,而不是什么调用类方法,或者编译时间的问题

VB本身设置不同的编译选项,生成代码都可以相差几倍速度了,看来64位CPU在数值计算方面速度优势很明显吖。

亿次加法耗时        VBA        VB(x86)        VB(x64)
5        11.1094         1.2636         0.3276
4        8.8672         1.0140         0.2652
3        6.6797         0.7644         0.2028
2        4.4297         0.5148         0.1248
1        2.2188         0.2496         0.0624

VB 和 VBA的测试代码
Dim i As Long, j As Long, t
t = Timer
For i = 1 To 100000000
  j = j + 1
Next i

VB的编译选项

[ 本帖最后由 灰袍法师 于 2011-6-2 20:58 编辑 ]
VB编译选项.jpg

TA的精华主题

TA的得分主题

发表于 2011-6-3 08:56 | 显示全部楼层
[广告] VBA代码宝 - VBA编程加强工具 · VBA代码随查随用  · 内置多项VBA编程加强工具       ★ 免费下载 ★      ★使用手册
原帖由 灰袍法师 于 2011-6-2 20:57 发表


的确应该是 生成的指令的效率问题,而不是什么调用类方法,或者编译时间的问题

VB本身设置不同的编译选项,生成代码都可以相差几倍速度了,看来64位CPU在数值计算方面速度优势很明显吖。

亿次加法耗时        VBA ...

的确,加大30倍也是VB快得多。两者相比近10倍。

TA的精华主题

TA的得分主题

 楼主| 发表于 2011-6-3 15:47 | 显示全部楼层
VC++编译同样的循环
long i,j;
for (i=1; i<=500000000;i++) {j++};

不打开任何优化,耗时2.34秒,比VB不打开任何优化的3.8秒快一点

打开优化,耗时0.000秒,也就是说编译器识别出这一个循环可以替换为 j = 500000000。

看来高级编译器的优化能力,比许多程序员的努力都强,哈哈哈。

[ 本帖最后由 灰袍法师 于 2011-6-4 04:51 编辑 ]

TA的精华主题

TA的得分主题

发表于 2011-6-3 16:19 | 显示全部楼层
原帖由 灰袍法师 于 2011-6-3 15:47 发表
VC++编译同样的循环
long i,j;
for (i=1; i

楼主懂得的语言太多啦!这个编译好象不是在运行,而是直接把偏移的地址给出。C中交换两个字符串也能这样快么?
A="ABC"
B="DEF"

TA的精华主题

TA的得分主题

 楼主| 发表于 2011-6-4 00:03 | 显示全部楼层
原帖由 贝妮 于 2011-6-3 16:19 发表

楼主懂得的语言太多啦!这个编译好象不是在运行,而是直接把偏移的地址给出。C中交换两个字符串也能这样快么?
A="ABC"
B="DEF"


这个快不是机器指令的效率提高,而是编译器直接用更简单的等价代码替换了我的C++代码。

C++处理字符串比VB麻烦得多,如下代码交换5亿次要37秒,而VB做同样的事情只需要0.37秒!
于是我想也许是我用了错误的字符串类 #include <string>,这个类也许是很慢的。。。。。。
#include <string>
        string str1("ABCD");
        string str2("1234");
        string swap;
        i=0;
        for (i=1;  i < 500000001; i++)
        { swap = str1; str1 = str2; str2 = swap; }
于是换成以下代码,还是要10秒,比VB慢多了,于是我想strcpy这个函数估计也是很慢的。。。。。。
        char str1[] = "1111";
        char str2[] = "2222";
        char swap[] = "    ";
        for (i=1; i <= 500000001; i++)
        {
                strcpy(swap, str1);
                strcpy(str1, str2);
                strcpy(str2, swap);
        }

后来想起也许VB并没有交换字符串的值,而是交换字符串的地址而已,再改C++代码为以下,结果耗时0.211秒,比VB快50%左右
        char str1[] = "1111";
        char str2[] = "2222";
        char swap[4];
        for (i=1; i <= 500000001; i++)
        {
                *swap = *str1;
                *str1 = *str2;
                *str2 = *swap;
        }

结论:C++很强大很麻烦,只要找对方法,似乎做什么事情都比别的语言快,不过也不值得为了一倍两倍的加速去重新学习一门麻烦的语言。

直接把VBA代码在VB编译器优化编译就很好了。

[ 本帖最后由 灰袍法师 于 2011-6-4 04:56 编辑 ]

TA的精华主题

TA的得分主题

发表于 2011-6-4 23:56 | 显示全部楼层
如果将可以与E无关的程序的内容做成几个模块直接就是数组字典等的循环

输出也是一个数组什么的,

当然,前面会有形成数组什么可引用的东东,而在后面就是将数组变为一个交给E的输出

第一点做的几个模块是不是可以编译成一个可引用的dll?
而再通过这个DLL的运算传回E

这样做法会快些吗?
能做到吗?

TA的精华主题

TA的得分主题

发表于 2011-6-5 02:06 | 显示全部楼层
哈哈,如果你用汇编语言做,也许会更快。
您需要登录后才可以回帖 登录 | 免费注册

本版积分规则

手机版|关于我们|联系我们|ExcelHome

GMT+8, 2024-11-22 08:12 , Processed in 0.041812 second(s), 8 queries , Gzip On, MemCache On.

Powered by Discuz! X3.4

© 1999-2023 Wooffice Inc.

沪公网安备 31011702000001号 沪ICP备11019229号-2

本论坛言论纯属发表者个人意见,任何违反国家相关法律的言论,本站将协助国家相关部门追究发言者责任!     本站特聘法律顾问:李志群律师

快速回复 返回顶部 返回列表