严格地说VBA与VB只是语法体系和解释体系是相同的，但二者的具体实现却是独立的。所以，VBA代码不能直接用VB来编译为汇编指令的二进制。但是，VBE却可以将VBA源码编译为解释器能够认识的PCODE。
具体可了解Microsoft Office 2000 Developer，当年微软为了增强Office的竞争力，给广大开发者提供了这么一套工具。随着Office成为办公领域的事实标准，这些机制反而被隐藏了。随着时间的流逝，VB在专业市场的失宠，后来者很少知道有这么个东西。有可能是微软为了营造一种类似于开源模式的生态吧，毕竟工程加密就跟耍一样，就可以让VBA白嫖的资源丰富起来。
PCODE曾经让VB备受批评，主要因其低效性。但随着解释型语言大行其道(譬如Python)，VBA的解释器性能，反而享受了一波优越感。一来，VBA工程的代码量都不大，处理数据的量也不大。再加之硬件性能的普遍提升，一般场景下，肉眼很难区分性能差异。二来，VBA的执行往往不赶时间，只要比起手工方式更节约时间，都是效率工具。所以，逐句解释，逐句重复解释，也不是个事儿。
PCODE的编译模式，也就没啥突出的，急迫的需求。但又的确有很多人抱怨，数据量大了的时候，循环次数多了的时候，VBA堪称垃圾！于是很多人，情愿转向华而不实的Python，也不愿再搭理VBA。其实，这是极端情绪化的，对于解决问题而言，无疑是变相降低了效率(新学一门现代化的编程工具，投入是巨大的)。减少源码重复解释的次数，规范使用VBA，就能让VBA的性能提升N个档次。所以，笔者提过的那些知识点，使用时稍加注意，就大功告成啦。
笔者在以往的分享中，曾经也提过VBE的PCODE编译，但不是太主张，为什么呢？
VBA依赖桌面Office的运行环境，便捷是其头号优点！这对于很多IT严格管制的公司而言，简直就是提升自己和工作效率的福利！然而，PCODE编译，需要链接器(运行链接器才能将解释器的伪指令链接到DLL中)，这个在Office里是真没提供，需要VBA们自行拷贝1个到Office的支持目录。
如果可以运行链接器(Link.exe)，那为何不直接运行VB6.EXE呢？毕竟后者还可以编译为其他编译型语言那样的汇编指令，这可更高效呀！更何况VBE的PCODE编译，跟VB6里的一样，并不能直接将Office里的任何VBA语句都能编译成PCODE。
所以，这事就很鸡肋！这大概就是微软不再提这档子事的原因了吧。若是仍然不信，可以到VB相关论坛上去搜索，有很多介绍的帖子。若是看不懂怎么操作的，可以留言。
更多精彩内容，尽在BtOfficer，欢迎关注！