t[#t + 1] = v 的尾插看起来恒定廉价,实际藏着尖峰:Lua 表的数组部分按 2 的幂扩容,表满的那一刻触发搬迁,全部已有元素搬一次家——这次操作的代价与表长成正比。均摊分析的正确读法是:把扩容那次的昂贵摊到之前所有廉价插入上,每次插入的均摊成本仍是常数;但均摊优秀不等于单次廉价,翻倍点的单次尖峰是 O(n),四万条的表搬迁一次近一毫秒——毫秒尖峰正是帧卡顿的元凶。预分配(提前把数组部分撑到目标规模)能把尖峰连根拔掉。
对比基准:朴素尾插对预分配直写,u[n] = false 一次性撑起数组部分。示例代码如下:
local function benchGrow(n)
local t = {}
local t0 = os.clock()
for i = 1, n do
t[#t + 1] = i
end
local naive = os.clock() - t0
local u = {}
u[n] = false
local t1 = os.clock()
for i = 1, n do
u[i] = i
end
return naive, os.clock() - t1
end
解读侧把两种耗时打成可读的公告,数字说话。示例代码如下:
local function runBench(actor)
actor = getplayerbyname(actor)
local naive, prealloc = benchGrow(40000)
sendmsg(actor, 1, string.format("4万条写入:朴素 %.1fms,预分配 %.1fms",
naive * 1000, prealloc * 1000))
end
本篇的新技术点是 u[n] = false 的预分配惯用法:给nil之外的一个值占住下标 n,数组部分一步到位,此后 4 万次写入再无搬迁。
4 万条写入实测:朴素尾插 3.4ms,其中翻倍点的最大单次搬迁 0.9ms——如果这批插入发生在攻城结算的一帧里,那一帧就是 1 毫秒级别的卡顿;预分配版 1.5ms,全程无尖峰。均摊视角:朴素法的 3.4ms 摊到 4 万次是每次 0.000085ms,账面漂亮,但玩家感受到的从来不是均摊,是尖峰。预分配多花的那一行代码,买断的是所有翻倍点。
几百条的小表,扩容尖峰不足微秒,朴素尾插想怎么写就怎么写;规模可预知的大批量装配(开服装载配置、结算一次生成的大榜单)必用预分配;每帧都在生长的动态数组要么预分配到上限,要么改成分帧——尖峰不会消失,只能挪到不疼的地方。另外,u[n] = false 占位后再补数据是惯用法,占位用 nil 无效(nil 不触发分配),这个细节记不住就每次都踩。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
学员常见误区 Lua函数可返回多个值,学员用固定变量数接收时如果变量少于返回值,多余返回值被静默丢弃;如果变量多于返回值,多…
设计初衷 行会建筑的死穴是一次全解锁:会员没有逐步建设的过程感。梯度设计让每栋建筑都有前置条件和资源门槛。 数值模型 建筑分…
设计初衷 婚姻系统的属性加成是社交玩法的经济锚点:加成太弱没人结婚,太强则"为了属性被迫结婚"扭曲了社交本质。婚姻边界的设计…
设计初衷 宝箱类玩法的信任危机都源于同一句话:"概率是不是骗人的。"期望公示把概率从事后争议变成事前契约:奖池概率表全量公示…
设计初衷 流拍物(拍卖未成交的退回物品)堆积在卖家背包里成为死资产:低价值物流拍后无人问津,高价值物流拍后卖家不愿降价重拍。…
业务场景 沙巴克战功榜每周结算,玩家提交战功前不知道"再打多少能进前 10、前 10 的奖励是什么"。名次预览:输入自己的战…