最近在做lua的内存优化,发现项目在读取配置表的时候占用了大约70MB的内存。而实际的protobuf的二进制文件总共大小才10MB左右,所以感觉可优化的空间还是蛮大的,就深入检查了问题所在。
一般的项目配置表大致是这个样子,第一列一般是主键id,顺序的整形数字,一般从1开始。列是策划写的对应的内容名称。项目里使用的protobuf作为存储媒介,采用云风的lua protobuf工具转换成可以读取的lua table表。这里不是说protobuf存储的缺陷。protobuf本身是一个很优秀的序列化和反序列的工具,云大的工具也无可挑剔,但是作为读取配置文件来讲功能上有点冗余。配置表一般都是只读文件,在游戏初始化的时候一次或者分批读入,不存在动态改变的时候,所以完全可以转换成一个干净的lua数组来存储在内存中。
一般首先想到的应该是这种lua table结构:
table =
{
[1] =
{
"id" = ...,
"event_name" = ...,
"event_level" = ...,
"all_variate_id" = ...,
.
.
.
.
.
},
[2] =
{
"id" = ...,
"event_name" = ...,
"event_level" = ...,
"all_variate_id" = ...,
.
.
.
.
.
},
.
.
.
}
我写了一个测试表,测试表的结构是这样的:
列从test1至test99,行从1至100,表中内容全部是数字。按照前边实例的结构转换成乱table表占用内存702KB,明显还是过大。如果一张表全部是数字的话,按照lua中数字存储全部是double类型来计算,数字内容部分大概是80左右KB的容量,抛去lua中table一些固有的内存开销,那么大部分内存浪费在了字符作为key的hash上。
解决的办法就出来了,直接用存储成二维数组,占用内存变成309KB,占用少了差不多一半。那么问题也就随之来了,如何读取。我们还是想像以前一样通过id和对应列名读取。例如local a = table[1].test1这样读取,这就需要把之前的table结构更改一下。
我们首先需要把对应的列表映射成列号,这个一般项目都有excle导出工具,可以很简单的找出映射关系并记录下来。还以上边测试表为例子,我们在数据表table外部创建一张映射表:
cloumntable =
{
"test1" = 1,
"test2" = 2,
"test3" = 3,
.
.
.
"test99" = 99,
}
原先的表结构更改为:
table =
{
[1] = {
cloumn = cloumntable,
field = {
1,
.
.
.
99 = 99,
}
}
[2] = {
cloumn = cloumntable,
field = {
1 = 1,
.
.
.
99 = 99,
}
}
.
.
.
}
这样修改完后,还需要重新设置一下table的元表,为table表添加一个get方法,至于如何添加可以百度lua添加set和get函数,里面有详细的介绍。
get函数:
function getter(selftable,cloumnName)
return selftable.field[cloumn[cloumnName]]
end
这样就可以按照之前的table[1].test1这样的读取方式读取了。