参数顺序影响调用优化吗？为何无法重现EASTL的函数调用优化？

首先明确EASTL里那个优化的核心：针对成员函数调用约定的适配——直接调用成员函数时，this会被放入专用寄存器（比如x86-64的rcx），和普通参数寄存器不重叠；但通过外部Invoker代理时，如果把this当作第一个普通参数处理，会占用普通参数寄存器，导致后续参数需要移位调整。EASTL的做法是把this移到参数列表末尾，让调用时的寄存器分配完全匹配成员函数的原生约定，避免参数移动。

你的实现没能重现该优化，核心问题大概率出在类型擦除的方式和Invoker的设计上，和byte array本身无关，但reinterpret_cast+无类型存储的组合会让编译器丢失关键类型信息，导致优化失效：

1. 类型信息丢失导致编译器无法识别调用场景 #

你用byte array存储Callable对象，再通过reinterpret_cast强制转换，这种通用化的类型擦除会让编译器完全不知道实际要调用的是成员函数、普通函数还是lambda。EASTL的实现是针对不同Callable类型做了模板特化（比如单独处理成员函数指针、普通函数、 functor），每种类型对应专属的Invoker逻辑——编译器能看到明确的类型匹配，才能针对性地做参数顺序优化。而你的通用Invoker无法让编译器识别出当前处理的是成员函数，自然不会触发参数顺序的优化。

2. Invoker签名未匹配优化逻辑 #

EASTL针对成员函数的Invoker签名是把this放在参数列表末尾的，比如对应成员函数Ret (T::*)(Args...)，Invoker的签名会是Ret(void*, Args..., T*)。如果你的Invoker仍然把this作为第一个参数传入，即使你在逻辑上调整了顺序，编译器也无法生成匹配成员函数调用约定的汇编，参数移动操作依然会存在。

修正方向 #

（1）针对不同Callable类型做模板特化 #

放弃单一通用的Invoker，为普通函数、成员函数、可调用对象分别编写特化逻辑，让编译器能识别具体的调用场景：

// 普通函数的Invoker特化
template<typename Ret, typename... Args>
struct Invoker<Ret(*)(Args...)> {
    static Ret invoke(void* func, Args... args) {
        return reinterpret_cast<Ret(*)(Args...)>(func)(std::forward<Args>(args)...);
    }
};

// 成员函数的Invoker特化（this放在参数末尾）
template<typename Ret, typename T, typename... Args>
struct Invoker<Ret(T::*)(Args...)> {
    static Ret invoke(void* func_ptr, Args... args, T* this_ptr) {
        return (this_ptr->*reinterpret_cast<Ret(T::*)(Args...)>(func_ptr))(std::forward<Args>(args)...);
    }
};

（2）调整存储与绑定逻辑 #

在绑定成员函数时，要对应Invoker的签名，把this参数放在参数列表的最后传递。同时用std::aligned_storage_t替代裸byte array，保证内存对齐的同时，保留模板参数带来的类型信息提示。

（3）避免过度通用化的类型擦除 #

尽量让编译器在编译期能看到Callable的具体类型，不要用单一的void*承载所有类型的Callable。通过模板特化，让每种Callable类型对应专属的存储和调用逻辑，编译器才能进行激进的优化。

按照这个思路调整后，开启-O2优化时，编译器就能识别成员函数的调用场景，生成不需要参数移动的汇编代码，重现EASTL的优化效果。

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