你好，我是温铭。

在 OpenResty 中，除了字符串经常出现性能问题外，table 也是性能的拦路虎。在之前的章节中，我们零零散散地介绍过 table 相关的函数，但并没有专门提到它对性能方面的提升。今天，我就带你专门来聊聊，table 操作对性能的影响。

不同于对字符串的熟悉，开发者对于 table 相关的性能优化知之甚少，这主要有两个方面的原因。

  • 其一，OpenResty 中使用的是 Lua，是自己的 LuaJIT 分支，不是标准的 LuaJIT，也不是标准的 Lua。而大部分开发者并不知道它们之间的区别，倾向于使用标准 Lua 的 table 库来写 OpenResty 代码。
  • 其二，在标准 LuaJIT 和 OpenResty 自己的 LuaJIT 分支中，table 操作相关的文档都藏得非常深，开发者很难找到；而且文档中也没有示例代码，需要开发者自己去开源项目中寻找示例。

这就形成了比较高的认知壁垒，导致了两极分化的结果——资深的 OpenResty 开发者能够写出很高性能的代码，而刚入门的则会怀疑 OpenResty 的高性能是不是一个泡沫。当然，等你学习完这节课的内容，你就可以轻松地戳破这层窗户纸，让性能提升 10 倍不是梦。

在详细介绍 table 优化之前，我想先强调的一点是，table 相关的优化，有一个自己的简单原则：

尽量复用，避免不必要的 table 创建。

你先记住这一点，下面，我们就从 table 的创建、元素的插入、清空、循环使用等方面，分别来介绍相关的优化。

预先生成数组

第一步，自然是创建数组。在 Lua 中，我们创建数组的方式很简单：

1
2


local t = {}

上面这行代码，就创建了一个空数组；当然，你也可以在创建的时候，就加上初始化的数据：

1
2


local color = {first = "red", "blue", third = "green", "yellow"}

不过，第二种写法对于性能的损失比较大，原因在于每次新增和删除数组元素的时候，都会涉及到数组的空间分配、resize 和 rehash。

那么应该如何优化呢？空间换时间，是一种常见的优化思路。既然这里的性能瓶颈是动态分配数组空间，那么优化的方向，就可以是预先生成一个指定大小的数组。这样做虽然可能会浪费一部分的内存空间，但多次的空间分配、resize 和 rehash 等动作，就可以合并为一次完成了，效率高了不少。

事实上，LuaJIT 中的 table.new(narray, nhash) 函数，就是因此而新增的。

这个函数，会预先分配好指定的数组和哈希的空间大小，而不是在插入元素时自增长，这也是它的两个参数 narray 和 nhash 的含义。

下面我们通过一个简单的例子，来看下具体的使用。因为这个函数是 LuaJIT 扩展出来的，所以，在使用它之前，我们需要先 require 一下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


local new_tab = require "table.new"

 local t = new_tab(100, 0)

 for i = 1, 100 do

   t[i] = i

 end

另外，因为之前的 OpenResty 并没有完全绑定 LuaJIT，还支持标准 Lua，所以有些旧的代码会做这方面的兼容。如果没有找到 table.new 这个函数，就会模拟出来一个空的函数，来保证调用方的统一。

1
2
3
4
5
6
7
8


local ok, new_tab = pcall(require, "table.new")

  if not ok then

    new_tab = function (narr, nrec) return {} end

  end

自己计算 table 下标

有了 table 对象之后，下一步就是向它里面增加元素了。最直接的方法，就是调用 table.insert 这个函数来插入元素：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


local new_tab = require "table.new"

 local t = new_tab(100, 0)

 for i = 1, 100 do

   table.insert(t, i)

 end

或者是先获取当前数组的长度，通过下标的方式来插入元素：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


local new_tab = require "table.new"

 local t = new_tab(100, 0)

 for i = 1, 100 do

   t[#t + 1] = i

 end

不过，这两种方式都需要先计算数组的长度，然后再新增元素。显然，这个操作是 O(n) 的时间复杂度。就拿上面代码的例子来说，for 循环会计算 100 次数组的长度，这样下来性能自然不乐观，并且数组越大时，性能也会越低。

这一点又该如何解决呢？让我们看下 lua-resty-redis 这个官方的库是如何做的吧：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


local function _gen_req(args)

    local nargs = #args

      local req = new_tab(nargs * 5 + 1, 0)

    req[1] = "*" .. nargs .. "\r\n"

    local nbits = 2

      for i = 1, nargs do

        local arg = args[i]

        req[nbits] = "$"

        req[nbits + 1] = #arg

        req[nbits + 2] = "\r\n"

        req[nbits + 3] = arg

        req[nbits + 4] = "\r\n"

        nbits = nbits + 5

    end

    return req

en

这个函数预先生成了数组 req，它的大小由函数的入参来决定，这样就可以保证尽量不浪费空间。

然后，它使用 nbits 这个变量，来自己维护 req 的下标，自然就抛弃了 Lua 内置的 table.insert 函数和获取长度的操作符 #。你可以看到，在 for 循环中，nbits + 1 等一些运算，就是直接用下标的方式插入元素；并在最后用 nbits = nbits + 5 ，让下标保持一个正确的值。

这种的好处很明显，它省略了获取数组大小这个 O(n) 的操作，而是直接用下标访问，时间复杂度也变成了 O(1) 。当然，缺点也一样明显，那就是降低了代码的可读性，并且出错概率大大提高，可以说，这是一把双刃剑。

循环使用单个 table

既然 table 这么来之不易，我们自然要好好珍惜，尽量做到重复使用。不过，循环利用也是有条件的。我们先要把 table 中原有的数据清理干净，以免对下一个使用者造成污染。

这时，table.clear 函数就派上用场了。从它的名字你就能看出它的作用，它会把数组中的所有数据清空，但数组的大小不会变。也就是说，你用 table.new(narray, nhash) 生了一个长度为 100 的数组，clear 后，长度还是 100。

为了让你能够更清楚它的实现，下面我给出了一个代码示例，它兼容了标准 Lua：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


local ok, clear_tab = pcall(require, "table.clear")

  if not ok then

    clear_tab = function (tab)

      for k, _ in pairs(tab) do

        tab[k] = nil

      end

    end

  end

可以看到，clear 函数实际上就是把每一个元素都置为了 nil。

一般来说，我们会把这种循环使用的 table，放在一个模块的 top level 中。这样，在你使用模块中的函数的时候，就可以根据自己的实际情况来决定，到底是直接使用，还是 clear 后再使用。

比如我们来看一个实际应用的例子。下面这段 伪代码 取自开源的微服务 API 网关 APISIX，这是它在加载插件时候的逻辑：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


local local_plugins = {}

  function load()

    core.table.clear(local_plugins)

      local local_conf = core.config.local_conf()

    local plugin_names = local_conf.plugins

      local processed = {}

    for _, name in ipairs(plugin_names) do

        if processed[name] == nil then

            processed[name] = true

            insert_tab(local_plugins, name)

        end

    end

      return local_plugins

你可以看到，local_plugins 这个数组，是 plugin 这个模块的 top level 变量。在 load 这个加载插件函数的开始位置，table 就会被清空，然后根据当前的情况生成新的插件列表。

table 池

到现在，你就掌握了对单个 table 循环使用的优化方法了。那么更进一步，你还可以用缓存池的方式来保存多个 table，以便随用随取，官方提供的 lua-tablepool 正是出于这个目的。

下面这段代码，展示了 table 池的基本使用方法。我们可以从指定的池子中获取一个 table，使用完以后再释放回去：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


local tablepool = require "tablepool"

 local tablepool_fetch = tablepool.fetch

 local tablepool_release = tablepool.release

  local pool_name = "some_tag" 

local function do_sth()

     local t = tablepool_fetch(pool_name, 10, 0)

     -- -- using t for some purposes

    tablepool_release(pool_name, t) 

end

显然，tablepool 中会用到前面我们介绍过的几个方法，而且它的代码只有不到一百行，所以，如果你学有余力，我十分推荐你可以自己搜索并研究一下。这里，我主要介绍下它的两个 API。

第一个是 fetch 方法，它的参数和 table.new 基本一样，只是多了一个 pool_name。如果池子中没有空闲的数组，fetch 方法就会调用 table.new 来新建一个数组。

1
2


tablepool.fetch(pool_name, narr, nrec)

第二个是 release 这个把 table 放回池子的函数。在它的参数中，最后的 no_clear ，用来配置是否要调用 table.clear 把数组清空。

1
2


tablepool.release(pool_name, tb, [no_clear])

你看，我们前面介绍到的方法，到这里是不是就全部串联起来了？

不过，注意不要因此滥用 tablepool。tablepool 在实际项目中的使用并不多，比如 Kong 中就没有用到，APISIX 也只有少数几个调用。大多数情况下，不用 tablepool 的这层封装，也是足够我们使用的。

写在最后

性能优化，是 OpenResty 中的硬骨头，也是我们大家关注的热点。今天我介绍了 table 相关的性能优化技巧，希望能对你的实际项目有所帮助。

最后给你留一个作业题：你可以自己做个性能测试，对比下使用 table 相关优化技巧前后的性能差异吗？欢迎留言和我交流，你的做法和观点都是我希望听到的声音，也欢迎你把这篇文章分享出去，让更多的人一起参与进来。