Performance 在我的速度测试中，Lua表哈希索引比数组索引快。为什么？

我正在做一些测试，看看在哪里可以提高lua代码的性能

我正在阅读这份文件： 我认为使用整数作为表索引应该要快得多，因为它使用表的数组部分，不需要散列

所以我写了这个测试程序：

    print('local x=0 local y=0 local z=0')
    local x=0 local y=0 local z=0
    t0 = os.clock()
    for i=1,1e7 do
        x = 1
        y = 2
        z = 3
    end
    print(os.clock()-t0 .. "\n")


    print("tab = {1,2,3}")
    tab = {1,2,3}
    t0 = os.clock()
    for i=1,1e7 do
        tab[1] = 1
        tab[2] = 2
        tab[3] = 3
    end
    print(os.clock()-t0 .. "\n")


    print("tab = {[1]=1,[2]=2,[3]=3}")
    tab = {[1]=1,[2]=2,[3]=3}
    t0 = os.clock()
    for i=1,1e7 do
        tab[1] = 1
        tab[2] = 2
        tab[3] = 3
    end
    print(os.clock()-t0 .. "\n")


    print("tab = {a=1,b=2,c=3}")
    tab = {a=1,b=2,c=3}
    t0 = os.clock()
    for i=1,1e7 do
        tab.a = 1
        tab.b = 2
        tab.c = 3
    end
    print(os.clock()-t0 .. "\n")


    print('tab = {["bli"]=1,["bla"]=2,["blu"]=3}')
    tab = {["bli"]=1,["bla"]=2,["blu"]=3}
    t0 = os.clock()
    for i=1,1e7 do
        tab["bli"] = 1
        tab["bla"] = 2
        tab["blu"] = 3
    end
    print(os.clock()-t0 .. "\n")


    print("tab = {verylongfieldname=1,anotherevenlongerfieldname=2,superincrediblylongfieldname=3}")
    tab = {verylongfieldname=1,anotherevenlongerfieldname=2,superincrediblylongfieldname=3}
    t0 = os.clock()
    for i=1,1e7 do
        tab.verylongfieldname = 1
        tab.anotherevenlongerfieldname = 2
        tab.superincrediblylongfieldname = 3
    end
    print(os.clock()-t0 .. "\n")


    print('local f = function(p1, p2, p3)')
    local f = function(p1, p2, p3)
        x = p1
        y = p2
        z = p3
        return x,y,z
    end

    local a=0
    local b=0
    local c=0
    t0 = os.clock()
    for i=1,1e7 do
        a,b,c = f(1,2,3)
    end
    print(os.clock()-t0 .. "\n")


    print('local g = function(params)')
    local g = function(params)
        x = params.p1
        y = params.p2
        z = params.p3
        return {x,y,z}
    end

    t0 = os.clock()
    for i=1,1e7 do
        t = g{p1=1, p2=2, p3=3}
    end
    print(os.clock()-t0 .. "\n")

我已经按我预期的增加时间消耗的顺序排列了这些块。（我不确定函数调用，那只是一个测试。）但以下是令人惊讶的结果：

    local x=0 local y=0 local z=0
    0.093613

    tab = {1,2,3}
    0.678514

    tab = {[1]=1,[2]=2,[3]=3}
    0.83678

    tab = {a=1,b=2,c=3}
    0.62888

    tab = {["bli"]=1,["bla"]=2,["blu"]=3}
    0.733916

    tab = {verylongfieldname=1,anotherevenlongerfieldname=2,superincrediblylongfieldname=3}
    0.536726

    local f = function(p1, p2, p3)
    0.475592

    local g = function(params)
    3.576475

即使是应该导致最长散列过程的长字段名也比使用整数访问数组快。我做错什么了吗？

您所看到的文档的第6页（实际第20页）解释了您所看到的内容

但是，如果编写类似{[1]=true、[2]=true、[3]=true}的代码，Lua不够聪明，无法检测给定的表达式（在本例中为文字数字）是否描述数组索引，因此它会创建一个表，其中包含四个插槽 它的散列部分，浪费内存和CPU时间

只有在不使用键分配表时，才能获得数组部分的主要好处

table = {1,2,3}

如果您正在读取/写入已经存在的表或数组，您将不会看到处理时间上的大偏差

文档中的示例包括在for循环中创建表

for i = 1, 1000000 do
    local a = {true, true, true}
    a[1] = 1; a[2] = 2; a[3] = 3
end

---

所有局部变量都在循环中的结果。编辑：如siffiejoe所指出的，将长字符串延长到40字节

local x=0 local y=0 local z=0
0.18

tab = {1,2,3}
3.089

tab = {[1]=1,[2]=2,[3]=3}
4.59

tab = {a=1,b=2,c=3}
3.79

tab = {["bli"]=1,["bla"]=2,["blu"]=3}
3.967

tab = {verylongfieldnameverylongfieldnameverylongfieldname=1,anotherevenlongerfieldnameanotherevenlongerfieldname=2,superincrediblylongfieldnamesuperincrediblylongfieldname=3}
4.013

local f = function(p1, p2, p3)
1.238

local g = function(params)
6.325

---

此外，lua为不同的键类型执行不同的散列

源代码可以在这里查看，其中包含我将要讨论的代码

mainposition

函数处理关于执行哪个散列的决策

/*
** returns the `main' position of an element in a table (that is, the index
** of its hash value)
*/
static Node *mainposition (const Table *t, const TValue *key) {
  switch (ttype(key)) {
    case LUA_TNUMBER:
      return hashnum(t, nvalue(key));
    case LUA_TLNGSTR: {
      TString *s = rawtsvalue(key);
      if (s->tsv.extra == 0) {  /* no hash? */
        s->tsv.hash = luaS_hash(getstr(s), s->tsv.len, s->tsv.hash);
        s->tsv.extra = 1;  /* now it has its hash */
      }
      return hashstr(t, rawtsvalue(key));
    }
    case LUA_TSHRSTR:
      return hashstr(t, rawtsvalue(key));
    case LUA_TBOOLEAN:
      return hashboolean(t, bvalue(key));
    case LUA_TLIGHTUSERDATA:
      return hashpointer(t, pvalue(key));
    case LUA_TLCF:
      return hashpointer(t, fvalue(key));
    default:
      return hashpointer(t, gcvalue(key));
  }
}

当键是Lua_号码时，我们称之为

hashnum

/*
** hash for lua_Numbers
*/
static Node *hashnum (const Table *t, lua_Number n) {
  int i;
  luai_hashnum(i, n);
  if (i < 0) {
    if (cast(unsigned int, i) == 0u - i)  /* use unsigned to avoid overflows */
      i = 0;  /* handle INT_MIN */
    i = -i;  /* must be a positive value */
  }
  return hashmod(t, i);
}

---

这些散列分解为两条路径hashpow2和hashmod

LUA\u TNUMBER

use hashnum>hashmod和

LUA\u TSHRSTR

use hashstr>hashpow2

您正在使用哪个版本的LUA？我在没有jit的情况下使用LUA 5.2.4。不久前，我发现

{[1]=1，[2]=2，[3]=3}

实际上将条目放在散列部分，因此我预计它需要的时间比

{1,2,3}

或

t[1]长，t[2]，t[3]=1，2，3

，将条目放入数组部分。我也读过。它写在我链接的文档中。“t[1]，t[2]，t[3]=1，2，3”也是一个选项，我将在测试中包括它，谢谢。但我还是不明白其余的…谢谢你详尽的回答！我已经看过你提到的文件中的那部分了。我想知道的是，为什么在散列部分使用整数访问表的速度比其他任何东西都慢？为什么在哈希部分使用字符串访问表比在哈希部分使用整数更快，甚至比在数组部分使用整数更快？为什么字符串越长，访问速度就越快？散列不应该比纯数组索引花费更多的时间吗？字符串越长就越努力？@Mircode在微基准测试中根本没有考虑哈希所需的时间。即使您的“长”字符串也少于40字节（

LUAI_MAXSHORTLEN

），因此Lua将它们视为短字符串。短字符串在创建时会被散列，在您的例子中，这发生在编译/加载时，因为您的所有键在代码中都是常量。即使是真正的长字符串（>40字节）在第一次索引操作时也会被散列一次，这在您的度量循环之前，但至少您应该看到实际字符串比较的一些延迟。

#define hashpow2(t,n)           (gnode(t, lmod((n), sizenode(t))))

#define hashstr(t,str)          hashpow2(t, (str)->tsv.hash)
#define hashboolean(t,p)        hashpow2(t, p)


/*
** for some types, it is better to avoid modulus by power of 2, as
** they tend to have many 2 factors.
*/
#define hashmod(t,n)    (gnode(t, ((n) % ((sizenode(t)-1)|1))))


#define hashpointer(t,p)        hashmod(t, IntPoint(p))