一、直接看LuaJIT FFI调用C库的性能坑
很多用LuaJIT做开发的朋友，都会碰到一个问题：明明写的代码逻辑很简单，但调用C库的时候就是比预期慢，尤其是需要频繁调用的时候，性能差得更明显。其实核心原因就是调用过程中多做了两步额外动作：不必要的类型转换和内存拷贝。 举个生活化的例子：你要把一个写在小纸条上的名字，交给负责记录的C模块。如果你先把小纸条抄一遍，再给记录员，这就是多了一次内存拷贝；如果小纸条的文字风格和记录员要求的格式不对，你还要重新写一遍，这就是类型转换——这两步都是没用的，纯纯浪费时间，调用快不起来才怪。
1.1 为啥会多做这些无用功？
Lua和C是两个不同的运行体系，Lua里的字符串、数字、结构体，和C里的对应类型不是直接相通的。比如你传一个Lua的字符串给C的const char*，如果只简单传过去，其实LuaJIT可能会偷偷帮你做一次临时内存拷贝，避免后续修改Lua字符串的时候影响C那边；再比如你要传一个Lua的表给C的结构体，不提前处理的话，LuaJIT会把表的每个元素拆出来转成C类型，再组装成结构体，这中间就有类型转换的开销。
二、零开销调用的核心：把中间层全砍掉
要实现接近C原生的调用速度，核心就是把刚才说的临时拷贝和多余的类型转换全去掉。怎么做？其实就是让Lua的类型直接和C的类型对齐，不做任何额外的转换或复制，让两者直接打交道。 简单说就是：你拿什么给C，就直接用和C匹配的东西，别自己瞎转或者复制。
2.1 具体要避开哪些无用操作？
最常见的无用操作有两个：一是随便分配临时的内存缓冲区，二是用Lua的通用类型（比如string、table）直接传给C的特定类型，导致LuaJIT不得不做转换。要避开这两个，就得用LuaJIT FFI提供的原生能力，直接操作C的类型。
三、从反面到正面：完整示例看优化
以下示例统一用的技术栈是LuaJIT FFI，所有代码都是实际能跑的，注释也写得很清楚，能直观看到优化前后的区别。
3.1 错误用法（有拷贝和转换，性能差）
这个例子里，我们要调用C标准库的strlen，它需要一个const char*参数。Lua的字符串传过去的时候，因为没对齐，FFI会偷偷做一次临时拷贝，多了无用功。
-- 技术栈：LuaJIT FFI
local ffi = require("ffi")
-- 先定义C函数的原型，告诉FFI我们要调用C的strlen
ffi.cdef[[
size_t strlen(const char *s);
]]
local C = ffi.C -- 拿到C标准库的全局对象
-- 错误的调用方式：每次传Lua字符串，FFI会隐式创建一个临时的char*，做一次内存拷贝
local function bad_calc_strlen(lua_str)
-- 这里传lua_str，其实FFI内部会复制一份到临时内存，再传给C函数，多了拷贝开销
return C.strlen(lua_str)
end
-- 测试调用，你会发现能出结果，但每次都多做了无用拷贝，高并发的时候会卡
print(bad_calc_strlen("hello lua")) -- 输出：9
3.2 优化后的零开销用法（无拷贝无转换）
其实strlen的参数是const char*，只要Lua的字符串不被修改，FFI传的时候就不会做拷贝，因为只读的内存不需要复制。那我们换一个需要分配内存的场景，比如调用一个创建用户结构体的C函数，对比优化前后的区别。
-- 技术栈：LuaJIT FFI
local ffi = require("ffi")
-- 定义C的结构体和函数原型，这次是自定义的结构体，更能体现优化效果
ffi.cdef[[
// C语言里的用户结构体，包含名字和年龄
typedef struct {
char name[100]; // 固定100字节的名字数组
int age; // 整数类型的年龄
} User;
// 创建用户的C函数，传入名字和年龄，返回User结构体指针
User* create_user(const char* name, int age);
// 释放用户结构体的函数
void free_user(User* u);
]]
local C = ffi.C
-- 错误的创建方式：会多分配临时缓冲区，做两次内存拷贝
local function bad_create_user(lua_name, age)
-- 先申请一个临时的char数组，把Lua的字符串复制进去（第一次拷贝）
local temp_buf = ffi.new("char[?]", #lua_name + 1)
ffi.copy(temp_buf, lua_name) -- 把Lua字符串拷贝到临时buf（第二次拷贝）
-- 调用C函数，传临时buf的指针，还要再复制一次到结构体里（第三次拷贝）
local u = C.create_user(temp_buf, age)
return u
end
-- 优化后的创建方式：只做一次必要拷贝，没有任何额外开销
local function good_create_user(lua_name, age)
-- 直接在FFI里分配User结构体，这个结构体的name字段就是我们要的char数组，不需要临时buf
local user = ffi.new("User") -- 分配结构体，全程在FFI的原生内存，无Lua到C的转换
-- 只把Lua字符串拷贝到结构体的name数组，这是唯一必要的拷贝（因为结构体是C的内存，Lua字符串在Lua栈，必须拷一次但无额外）
ffi.copy(user.name, lua_name, #lua_name + 1)
user.age = age -- 整数直接赋值，完全匹配类型，无转换
-- 调用C函数，直接传结构体内部的name指针，无任何拷贝或转换
local u = C.create_user(user.name, user.age)
return u
end
-- 测试两个函数，你会发现功能一样，但优化后的性能会高很多，尤其是传长字符串的时候
local bad_user = bad_create_user("张三", 25)
local good_user = good_create_user("张三", 25)
print(bad_user, good_user) -- 输出两个不同的指针，功能正常
四、聊透核心细节：场景、优缺点、注意事项
4.1 适合用的场景
这个优化方法最适合对性能要求极高的场景，比如游戏开发（LuaJIT常用来做游戏逻辑脚本，频繁调用图形、物理引擎的C函数）、高并发服务端（用Lua处理请求，调用C的数据库驱动、JSON解析库），还有需要频繁处理大量数据的工具脚本，这些场景多一次拷贝就会多很多耗时，必须砍掉。
4.2 优缺点
优点很明显：能达到C调用C的接近原生的速度，减少的开销在高调用频次下会被放大，性能提升几倍甚至几十倍；而且代码结构清晰，直接用C的类型，不需要写中间的适配层，好维护。 缺点也很突出：需要对C的类型和内存管理有一定了解，容易踩指针的坑，比如不小心修改了只读的内存会崩溃；还有如果优化不好，反而会引入GC压力，比如随便分配大的FFI对象，而不是用Lua的轻量类型。
4.3 必须注意的坑
几个关键的注意点：第一，不要修改只读的内存，比如Lua的字符串对应的Cconst char*，是只读的，你写的话程序会崩溃；第二，FFI分配的大对象不要频繁创建销毁，会增加Lua的GC压力，尽量复用；第三，类型一定要严格匹配，比如传int就别传long，虽然LuaJIT会自动处理，但还是会有一点点转换开销。
五、总结
LuaJIT FFI的零开销调用，本质就是把Lua和C之间的中间转换层全部砍掉，让两者直接匹配，只做必要的操作。很多开发者觉得调用C库慢，其实都是因为自己加了很多无用的拷贝和转换，只要按示例里的方法，用FFI的原生类型，直接分配、直接赋值、直接传参，就能实现接近C原生的性能。这个方法虽然需要对C有一点基础，但掌握之后，就能轻松解决LuaJIT调用C库的性能瓶颈，适合很多对性能要求高的项目。
Comments