VBA为何慢？原来如此！

　　1、效率奇高

　　源码到机器指令，除了大循环那样的计算密集型的代码能感觉出与编译存在差异外，几乎与编译有相同的体验。据相关人士统计，VB/VBA的虚拟机性能与其他解释机制的虚拟机不相上下，甚至略胜一筹。毕竟VB/VBA的虚拟机，在1970年代就大行其道了，后来在微软Windows平台上经历这么几十年的迭代优化，想想也应该是翘楚才对得起呀。

　　2、无与伦比的源码调试

　　像C/C++等专业开发工具，都有专业的调试器。强大而全面，但是门槛也高啊，多少会写代码的都用不好也不是啥稀奇事。VB/VBA的IDE，不仅是编辑器，更是调试器。

　　VB/VBA的调试器（IDE），虽然无法调试多线程、也无法处理复杂的异常，更不能像专业调试器那样下各种复杂的断点，但是VB/VBA也用不着。因为VB默认是单线程的，VBA与GUI线程绑定更是单线程的。VB/VBA的安全封装，几乎不会发生预期以外的错误，其错误处理机制足以应对。

　　专业调试器一般针对编译后的二进制，即便其他解释机制的调试器，也是在字节码整体的基础上进行调试。所谓源码级调试，并非在源码上进行调试。要源码调试，编译型的则不太可能。因为编译器在编译的过程中还有大量的优化工作要做，源码翻译成机器指令与编译后的机器指令之间，可能存在不小的差异，从而致使源码调试没有意义。因此，源码调试只能建立在解释机制上，才能办到。

　　纵观各大解释机制的编程语言，唯有VB/VBA提供了逐行解释机制。其中原因之一逐行解释需基于COM，才能对源码进行动态感知。原因之二其他虚拟机对字节码有更复杂的优化处理，逐行解释的机器码与字节码最终的机器码之间存在差异，逐行解释没有意义。原因之三不像VB/VBA专为Office服务，其他虚拟机没有逐行解释的使用场景。

　　源码调试，可以动态预知源码执行情况，比如语句中变量的实时值。更重要的是，可以根据语句的执行结果，来动态修正源码，并观察修正是否正确。这种动态演示的调试方式，极大地降低了调试门槛，增加了编程的趣味性。

　　3、开发效率高

　　由于便捷的调试功能，便捷的使用环境(VBA附带在Office)，智能的编辑器，使得VB/VBA的开发效率相当之高。当然这种高效其实和调试功能一样，是指在其通用领域中。如果要用到其本身不鼓立的方式，比如多线程、那就需要自己封装，没有现成的轮子可用。这一点上，倒是不如其他能够不断得到技术更新支持的开发工具。

　　具体可参考《VB/VBA虚拟机(一)》，《VB/VBA虚拟机(二)》等系列文章。

　　1、比较基础不一样

　　尽管Python、C#等与VBA一样是解释型的，但是他们到Office地界上，已经是编译的二进制了，但VBA却连字节码都不是，而是源码。前者进行了提前处理，而后者是趁热处理。如此比较分优劣，未免太流氓。要比较，至少在VBA的Pcode基础上吧。其实VBA是支持编译为PCODE的，需要了解的朋友，可持续关注后续相关文章。

　　2、存在重复转换

　　Python、C#等会编译为字节码后，再统一交由虚拟机转换，不存在源码重复转换的问题。而VBA是逐行执行的，每次执行都会涉及源码的重复转换。如此比较分优劣，再次耍流氓。

　　3、VBA是基于COM的

　　COM接口，若使用不当，比如后期绑定，则会大大增加开销，降低性能。VBA基于COM，提供了强大的灵活性(可参考《VB/VBA的任性，从Variant开始》)和包容性，但同时也是为不规范提供了藏污纳垢的边边角角。

　　至于其他开发工具在Office上的优劣，可参考《Office开发，选VSTO，还是VBA，Python行吗？》《Python取代VBA？先问C#答应否！》以及其他文章中的相关分析。

　　若不深入理解COM，就很难使用科学的用法来提升VBA的性能。而VBA将COM这一复杂的技术，遮盖得严丝合缝，很少透露其蛛丝马迹。在这一点上，VBA的用户既幸运，又值得同情。

　　1、恰当使用编译机制

　　VB/VBA本身都提供编译机制，VB可以编译为二进制，VBA可以编译为PCODE。其中前者能极大地提升VBA代码性能。恰当结合PCODE，不仅避免重复解释提升性能，还能保证调试修改的结果和编译高度一致。

　　2、充分利用COM机制

　　VBA和Office都是基于COM的，而COM是跨二进制的。这就说明，VBA的编译机制不一定非得VB提供，C/C++，C#的都可以。

　　欢迎支持关注BtOfficer，不仅分享职业相关技术，更有职业相关工具。知其然，知其所以然，有立场，有原则，更多精彩内容等你哦！