5

在我最近的一次代码审查中，出现了一个关于一段 lua 代码的问题。有问题的代码正在刷新缓存并使用一些数据重新初始化它：

for filename,_ in pairs(fileTable) do
    fileTable[filename] = nil
end

-- reinitialize here

有什么理由不应该用这个代替上面的循环吗？

fileTable = { }

-- reinitialize here
4

3 回答 3

3

除非您有其他证据，否则最好相信 Lua 的垃圾收集：只需在需要时创建一个新的空表。

于 2013-04-26T15:53:40.453 回答
3

这是由于表调整大小/重新散列开销。创建表时，它是空的。当您插入一个元素时，会发生重新散列，并且表大小会增加到 1。当您插入另一个元素时，也会发生同样的情况。规则是，只要没有足够的空间（在数组或哈希部分）来容纳另一个元素，就会增长一个表。新尺寸是 2 的最小幂，可以容纳所需的元素数量。例如，当您插入一个元素时，如果一个表包含 0、1、2、4、8 等元素，则会发生重新散列。

现在，您所描述的技术保存了这些重新散列，因为 Lua 不会缩小表。因此，当您有频繁的填充/刷新表操作时，最好（在性能方面）像在您的示例中那样做而不是创建一个空表。

更新：

我做了一个小测试：

local function rehash1(el, loops)
    local table = {}
    for i = 1, loops do
        for j = 1, el do
            table[j] = j
        end
        for k in ipairs(table) do table[k] = nil end
    end
end

local function rehash2(el, loops)
    for i = 1, loops do
        local table = {}
        for j = 1, el do
            table[j] = j
        end
    end
end


local function test(elements, loops)
    local time = os.time();
    rehash1(elements, loops);
    local time1 = os.time();
    rehash2(elements, loops);
    local time2 = os.time();

    print("Time nils: ", tostring(time1 - time), "\n");
    print("Time empty: ", tostring(time2 - time1), "\n");

end

结果很有趣。在 Lua 5.1 上运行test(4, 10000000)nils 需要 7 秒，empties 需要 10 秒。对于大于 32 个元素的表格，空版本更快（表格越大，差异越大）。test(128, 400000)给 nils 9 秒，给空 5 秒。

现在在 LuaJIT 上，alloc 和 gc 操作相对较慢，运行test(1024, 1000000)nils 需要 3 秒，empties 需要 7 秒。

PS 请注意普通 Lua 和 LuaJIT 之间的纯粹性能差异。对于 1024 个元素表，普通 Lua 在大约 20 秒内完成了 100,000 次测试迭代，LuaJIT 在 10 秒内完成了 1,000,000 次迭代！

于 2013-04-26T16:25:56.320 回答
0

在 Lua 中分配新表是一项代价高昂的操作（对于几乎任何动态语言中的任何对象分配都是如此）。此外，不断地“丢失”新创建的 GC 会给性能和内存带来额外的压力，因为在 GC 真正声称它之前，每个创建的表仍将在内存中。

您示例中的技术以这些缺点换取显式删除表中所有元素所需的时间。这将始终节省内存，并且根据元素的数量，通常也可能会提高性能。

于 2013-04-26T15:24:23.860 回答