关于优化lua读取游戏配置表的一些看法

最近在做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这样的读取方式读取了。