大量动态加载DLL场景下，GetProcAddress性能及替代方案咨询

GetProcAddress的实际性能表现 #

• 首先明确：你不应该在每次调用目标函数时都调用GetProcAddress，这是典型的用法错误。正确的做法是加载DLL后一次性获取所有需要的函数指针并缓存，后续直接调用指针——这也是所有插件系统的常规操作。
• GetProcAddress的查找并非线性遍历字符串：Windows PE文件的导出表内置了哈希表优化，它会先计算输入函数名的哈希值，通过哈希表快速定位候选项，再做字符串比对确认（避免哈希冲突）。实测下来，哪怕是导出上千个函数的大型DLL，单次GetProcAddress调用耗时也仅在100-500纳秒区间，完全不会成为启动或运行时的性能瓶颈。
• 和预绑定函数的性能差距：预绑定是链接阶段将函数地址写入导入表，加载时由系统直接填充，调用时就是直接跳转；而缓存GetProcAddress获取的指针后，后续调用的性能和预绑定函数几乎完全一致——唯一的额外开销是第一次获取指针的几十纳秒，对于千万次调用来说可以忽略不计。

满足需求的替代方案 #

1. 缓存函数指针（最优低成本方案） #

这是对现有架构改动最小的优化：加载DLL后，一次性调用GetProcAddress获取所有需要的函数指针，将其存储到全局结构体、类成员或插件管理对象中，后续直接通过指针调用函数。这种方式既保留了DLL可替换的特性，又完全消除了重复查找的性能损耗。

2. 自定义导出接口结构体 #

在每个插件DLL中导出一个统一的初始化函数，该函数返回一个包含所有插件接口函数指针的结构体。主程序仅需调用一次GetProcAddress获取这个初始化函数的地址，就能一次性拿到所有需要的接口指针，减少GetProcAddress的调用次数，同时便于接口的统一管理：

// 主程序与插件共享的头文件定义
typedef struct {
    void (*InitPlugin)(void);
    int (*ProcessData)(const char* input);
    void (*ShutdownPlugin)(void);
} PluginInterface;

// 插件DLL中的实现
__declspec(dllexport) PluginInterface* GetPluginInterface() {
    static PluginInterface api = {
        InitPluginImpl,
        ProcessDataImpl,
        ShutdownPluginImpl
    };
    return &api;
}

3. 使用COM接口 #

COM是Windows原生的跨模块松散耦合解决方案，通过IID/CLSID获取接口指针，底层依然依赖GetProcAddress，但提供了更规范的版本管理、生命周期控制和错误处理机制。适合大规模插件系统的长期维护，不过需要学习COM的基本规范，有一定的入门成本。

4. Windows延迟加载（Delay Load） #

使用VC++的延迟加载特性，链接时指定延迟加载目标DLL，系统会在第一次调用该DLL中的函数时自动完成加载和地址解析，并缓存指针。这种方式无需手动调用GetProcAddress，语法上和调用普通函数完全一致，同时保留了DLL可替换的灵活性。需要注意配置延迟加载的错误回调，处理DLL缺失等异常情况。

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