VBA的虛擬機器，當然牛逼啦，只有五十幾K，全彙編實現。

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的虛擬機器（二）》，《 VB/VBA的虛擬機器（三） 》等系列文章。

1、比較基礎不一樣

儘管Python、C#等與VBA一樣是解釋型的，但是他們到Office地界上，已經是編譯的二進位制了，但VBA卻連位元組碼都不是，而是原始碼。前者進行了提前處理，而後者是趁熱處理。如此比較分優劣，未免太流氓。要比較，至少在VBA的Pcode基礎上吧。其實VBA是支援編譯為PCODE的，需要了解的朋友，可持續關注後續相關文章。

2、存在重複轉換

Python、C#等會編譯為位元組碼後，再統一交由虛擬機器轉換，不存在原始碼重複轉換的問題。而VBA是逐行執行的，每次執行都會涉及原始碼的重複轉換。如此比較分優劣，再次耍流氓。

3、VBA是基於COM的

COM介面，若使用不當，比如後期繫結，則會大大增加開銷，降低效能。VBA基於COM，提供了強大的靈活性(可參考《VB的任性，從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#的都可以。

具體問題具體分析，不要貶低vba。我長期用vba，沒感覺多慢。拙劣的程式碼，拙劣的碼農，一知半解的設計者，敗壞了vba。