Lua遍历结构体数组时如何提升性能？

背景 #

为游戏引擎集成Lua脚本接口，从luabridge切换到sol2后，性能测试结果远低于预期。提取独立测试用例对比原生C++、sol2、纯Lua+Light Userdata的性能，耗时差距明显。

测试耗时数据 #

C++                  elapsed time: 0.002736s
Sol (Container)      elapsed time: 0.999166s
Lua (Light Userdata) elapsed time: 0.338946s

疑问 #

1. 这种性能差距是否符合预期？
2. 此类场景下有没有机会达到接近原生C++的性能？

环境信息 #

• LuaJit（最新主分支）
• sol2（最新主分支）
• 编译器：MSVC19
• 操作系统：Windows 11

性能差距是否符合预期？ #

是的，这种差距在脚本与原生代码的交互场景中完全符合预期，核心原因包括：

• 动态特性开销：Lua是动态类型语言，属性访问需要做类型检查、哈希表查找（sol2的userdata依赖元表实现属性访问）；而C++是静态编译，直接内存访问，无额外开销。
• 跨语言交互成本：sol2和手动Light Userdata都需要在Lua栈与C++之间传递数据，每次函数调用、属性读写都涉及栈操作和类型转换，这部分是不可避免的额外耗时。
• 执行模式差异：Lua循环是解释执行，C++循环会被编译器深度优化（比如循环展开、向量指令生成），执行效率天差地别。

如何接近原生C++的性能？ #

想要大幅缩小差距，核心思路是减少跨语言交互次数，让Lua尽可能少地调用C接口，把批量操作放在C侧完成：

1. 批量操作封装
   把遍历数组并更新的逻辑直接封装成C++函数，暴露给Lua调用。比如直接让Lua调用你已有的c_Update函数，而非自己遍历数组。这样每次调用只做一次跨语言交互，而非5000次。

修改sol测试的Lua代码示例：

function Update()
    -- 直接调用C++的批量更新函数
    c_Update()
end

2. 使用LuaJIT FFI直接访问内存
   LuaJIT的FFI可以绕过Lua栈，直接在Lua中访问C结构体的内存布局，性能接近原生。直接把Transform数组的指针传给Lua，用FFI定义结构体后直接遍历内存：

示例代码：

local ffi = require("ffi")

ffi.cdef[[
struct Transform {
    float position_x;
    float position_y;
    float position_z;
    float scale_x;
    float scale_y;
    float scale_z;
};
]]

function Update(transforms_ptr, count)
    local transforms = ffi.cast("struct Transform*", transforms_ptr)
    for i = 0, count - 1 do
        transforms[i].position_x = transforms[i].position_x + 0.01
        transforms[i].scale_x = transforms[i].scale_x + 0.01
    end
end

这种方式下，LuaJIT会把循环编译成接近原生的机器码，性能能大幅提升，甚至可达到C++性能的80%以上。

3. 优化sol2使用方式
   如果坚持用sol2，可做以下优化：

• 保持SOL_ALL_SAFETIES_ON 0的设置，禁用不必要的安全检查
• 直接传递数组指针而非std::vector<Transform*>，减少容器转换开销
• 缓存Lua循环中的属性访问逻辑（比如提前获取元表的getter/setter），但效果有限

4. 避免逐元素调用C++函数
   你的Light Userdata测试中，每次循环都调用GetLightTransform、GetPositionX等C函数，带来大量栈操作开销。可合并操作：一次性获取整个数组的内存指针，在Lua中直接计算后批量写回，或直接在C中完成批量更新。

总结 #

脚本语言不可能完全达到原生C的性能，但通过批量操作封装和LuaJIT FFI，可以把性能差距缩小到可接受的范围。对于游戏引擎中的高频操作，优先把核心逻辑放在C侧，Lua只负责触发调用或处理非性能敏感的逻辑。

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