为什么VBA的TypeName函数处理Dictionary类时运行速度极慢？

问题原因说明 #

1. TypeName对Dictionary调用慢的核心原因
   Dictionary属于Scripting Runtime库的外部COM对象，并非VBA原生内置类型。VBA的TypeName函数检查内置类型（如字符串、数值、原生Collection等）时，可直接在VBA运行时内部读取类型标识，耗时极短；但检查外部COM对象时，需要调用COM的IDispatch接口跨组件查询类型信息，这类跨边界调用的固有开销远高于内置类型查询。
   你测试的其他外部对象（如RegExp、Word文档对象）调用速度更快，是因为这类对象的类型元数据在对应库初始化时已经被VBA运行时预加载，而Scripting.Dictionary的类型信息默认不会预加载，首次查询时需要实时拉取。

2. 首次调用慢后续调用快的原因
   VBA运行时会对已经查询过的COM对象类型元数据做缓存，首次批量调用TypeName查询Dictionary类型时，运行时已经完成了Scripting.Dictionary类型信息的拉取和缓存，后续调用可直接读取缓存内容，耗时就会降到和其他对象一致的水平。
   你自行编写的isDictionary方法首次调用慢、后续调用快，以及首次用Dictionary(Key)语法访问元素慢的现象，本质都是同一逻辑：首次访问COM对象的属性/默认成员时，需要先完成接口绑定、成员调度ID解析，相关信息缓存后，后续访问就不会再有额外开销。

优化方案 #

如果要完全消除这类首次调用的性能开销，可采用两种方案：

• 若项目允许固定引用，提前添加「Microsoft Scripting Runtime」的早期绑定引用，改用TypeOf JsonValue Is Dictionary做类型判断。该判断属于早期绑定的类型检查，不需要走COM类型查询流程，速度远高于TypeName调用，也不存在首次开销问题。
• 若需要做通用分发无法添加固定引用，可以在程序初始化阶段预先创建一次临时Dictionary对象，执行一次TypeName调用或属性访问，提前完成类型信息缓存，避免业务逻辑执行时出现卡顿。

针对你使用的VBA-JSON库的场景，直接修改库中对应的类型判断逻辑即可完成优化。

内容的提问来源于stack exchange，提问作者Brattamob