Lua的CPU开销性能优化
- 作者:admin
- /
- 时间:2017年09月14日
- /
- 浏览:12312 次
- /
- 分类:厚积薄发
这是一篇着重介绍如何写好Lua代码,并做好优化工作的技术文章。文中笔者并没有介绍那些通俗的优化方法,而是首先总结了自己在优化过程中常见的性能问题,并通过实际优化案例的分析,来为大家提供更为实在的参考。
大家好,我是舒航,现任职于心动网络,主要负责《仙境传说RO:守护永恒的爱》(以下简称“RO”)的优化工作。今天主要想和大家分享一下,我这段时间在优化Lua的CPU性能方面的一些经验。
上一篇文章主要讲的是写一个LuaProfiler的思路,即如何快速定位到内存和CPU问题。而这一篇则着重于介绍如何写好Lua代码,以及优化的一些经验。在我优化RO和隔壁项目组手游的CPU性能时,发现CPU性能问题非常个性化,两个项目遇到的问题截然不同。而通用的Lua性能优化的Tips,往往并不能解决问题。所以这篇文章的前半部分是我总结的优化过程中常见的性能问题,后半部分是实际优化案例的一个分析,希望这样的形式更能帮到大家。
常见优化
首先需要说明的是,在我们项目中用的是Lua5.3,并且没有用到LuaJIT。
常见优化主要是参考了Lua作者Roberto Ierusalimschy所写的Lua性能优化建议:
https://www.lua.org/gems/sample.pdf
一、使用局部变量
这个点是绝大部分Lua性能问题产生的原因,尤其是和一个频繁调用的函数组合,会产生大量的开销。总的来说,我们在一个频繁调用的函数内,应该避免重复地去查询Table,应该把Table内我们常用的值缓存起来。
这里的值通常有两种: 1)函数 2)对象
虽然Lua是first-class,但是我发现实际使用中,大家意识上还是认为函数有别于其他值。所以分开来列举,方便大家对号入座。
使用局部变量是优化Lua性能的一条重要准则。
不管是函数还是对象,不管是Lua自身的库,还是我们自己写的,在Lua中都是储存在_G中的某个节点下。当我们调用一个函数/对象的时候,Lua首先会去他们的表中查找到这个函数/对象,而我们使用局部变量的话,由于Lua的局部变量是储存在寄存器(这里的寄存器不对应CPU的寄存器)内的,所以这个访问就会快很多。更严重的是,如果使用的是父类的函数/对象,还会触发__index,这样不仅会有额外的耗时还有内存开销。
对于不熟悉Lua的开发者来说,容易忽视局部变量的使用,而有些时候这会造成比较严重的性能问题。比较常见的就是写UI的同学在一个定时器或者一个循环内,使用GetComponent来获取组件然后进行一些操作。由于没有用变量缓存起来,每次用完了就抛弃,再用再获取。这不仅会造成很大的耗时,还会造成很大的内存开销,而写UI的工作又容易被大家所忽视,所以目前为止,我发现大部分项目这一块都有优化的空间。
这里提供了一段缓存Lua函数的代码(摘自Roberto原文):
function memoize(f)
local mem = {}
setmetatable(mem, { __mode = "kv" })
return function(x)
local r = mem[x]
if r == nil then
r = f(x)
mem[x] = r
end
return r
end
end
二、使用对象池
现在大部分团队,在使用Lua的时候,一般只用来写一些UI界面。而UI界面经常交给项目组的新人来做,以熟悉项目代码,所以这里的性能问题很容易被大家所忽视。这里经常遇到的性能问题一般出现在复杂滚动列表的重用、消息协议的重用、以及C#对象的重用中。
在我帮隔壁项目组优化性能的时候,就发现一个有趣的现象。他们项目Lua使用的不重度,但是平均每帧分配内存3.4KB,而RO高峰时期的内存分配也只有0.5KB,是RO的17倍。每帧Lua耗时在0.47ms,是RO的20%-30%。总体来说,对于普通使用Lua的团队来说这里面已经有很大的性能问题了,只是总量比较少,影响不是那么大。
而造成这么大性能问题的原因只有两个,一个是在一个定时器内频繁地给GameObject设位置,一个是每隔几帧收发一条移动消息。最后优化成,设位置时避免了重复创建LuaVector3,移动消息做了个简单的对象池。
优化了这两条以后,不管是每帧分配内存,还是CPU耗时都降低了50%。而在所有的项目中,除了使用局部变量,其他优化中最显著的就是使用对象池了。因为正确地使用对象池能有效地减少创建新对象的过程,在Lua中也就是newindex这个函数的耗时明显减少。newindex减少了以后,不仅避免了频繁开辟回收内存,还能避免额外的CPU开销。尤其是使用对象池缓存一个经常复用的对象时,这样的优化更明显,比如说LuaVector3、GameObject、滚动列表中的对象。
三、字符串拼接使用table.concat
这个问题在很多优化Tips里经常提到,相信大家也不陌生。究其原因,是因为Lua的String是内部复用的,当我们创建字符串的时候,Lua首先会检查内部是否已经有相同的字符串了,如果有直接返回一个引用,如果没有才创建。这使得Lua中String的比较和赋值非常地快速,因为只要比较引用是否相等、或者直接赋值引用就可以了。而另一方面这个机制使得Lua在拼接字符串上开销比较大,因为在一些直接持有字符串buffer的语言中,往往可以直接把后者的buffer插入到前者的buffer的末尾,而Lua先要遍历查找是否有相同的字符串,然后会把后者整个拷贝然后拼接。
尽管是这样,我们还是有一些手段来优化Lua的字符串拼接,使用table.concat来代替。通过查看Lua的源码可以发现,这里的原理主要是table.concat只会创建一块buffer,然后在此拼接所有的字符串,实际上是在用table模拟buffer;而用“..”来连接则每次都会产生一串新的字符串,开辟一块新的buffer。这个问题在《Programming in Lua》一书也有提及:
local buff = ""
for line in io.lines() do
buff = buff .. line .. "\n"
end
-- 这段代码读取一个350kb大小文件的时候需要约1分钟,同时会移动(开辟后又被回收)50GB内存
这个问题确实真实出现过,我有一次发现的一个性能问题就是因为写聊天界面的同学,每次都会用旧的聊天字符串,拼接上新增的聊天字符串得到一串新的聊天字符串。以致于当聊天信息过猛的时候,只要几分钟内存就会爆炸。但是相比较前面两点,这个问题对内存的影响更大,对CPU耗时的影响比较小。
四、优化配置表
--如果polyline内有一百万个点,则下面的表结构会占用95kb内存
polyline = {
{x = 1, y = 2},
{x = 3, y = 4},
{x = 5, y = 6},
...
}
--这样优化可以减少到65kb
--只是我们不得不使用polyline[1][3]来代替比较直观的polyline[1].x了。
polyline = {
{1, 2},
{3, 4},
{5, 6},
...
}
--这样优化最终可以减少到24kb
--我们必须使用polyline.x[2]来代替polyline[2].x
polyline = {
x = {1, 3, 5 ... },
y = {2, 4, 6 ... }
}
对于我们RO来说,table配置表就占了几十兆的内存,每一点小的优化都能节省很多内存空间。通过平时定义配置表的谨慎小心,再配合之前UWA的这篇文章Lua配置表存储优化方案,能给项目带来非常可观的优化空间。
五、细枝末节
以下是一些比较小的优化,但确实出现过。所以列举出来供大家参考,另外如果想写出完美的Lua代码的话强烈建议读一下Roberto的原文。
1)使用闭包代替loadstring()
loadstring(string.format("return %d", i))
function oploadstring (k)
return function () return k end
end
loadstring总是会动态地编译传入的字符串,而这个操作是非常耗时的。有时候我们可以使用闭包的形式来达到一样的效果,而且开销更小。
2)使用pairs代替next
next总是从第一个非nil值开始遍历,直到找到一个非nil值,在删除一个表或者一个足够空的表时,很慢。使用next删除一个10万个元素的表时,耗时约为20秒。而使用pairs仅需要0.04秒。
3)不要在for循环中创建表和闭包
4) 重用coroutine
--lua中的coroutine本身是不支持重用机制的,但是我们可以使用一些小技巧来实现它。
co = coroutine.create(function (f)
while f do
f = coroutine.yield(f())
end
end)
5)用C实现一些功能
如果性能实在吃紧,但是有苦于不能使用LuaJIT,可以用C实现一些功能,这样可以使模块的性能可优化的空间大大增加。需要注意的是,使用C越多,则LuaJIT能优化的越少,这两者是不能叠加的。目前我们项目中并没有使用到C来实现一些模块,一来是纯用Lua性能并没有那么吃紧,二来是如果使用C来实现一些功能就失去了使用Lua的意义。反正都不能热更,那还不如直接用C#实现。只要小心一些,用Lua还是用C写不会是性能的瓶颈。
实际案例分析
广度搜索的Lua写法优化
通用的优化经验相信大家都有所了解,这里再给大家分享一段我自己写Lua代码的优化过程。这段代码是求解一个无向图中的最短路径问题。在一个773个顶点,812条边的无向图中,求任意一点到原点(一个特殊点,即local origin = 10000)的最短路径。这个无向图储存在一个table中,每个顶点有个全局ID作为key,children记录了该顶点的邻接点,示意如下:
graph = {
[ID] = { children = { ID1, ID2, ID3 } },
[ID1] = { ... },
[ID2] = { ... },
...
}
原始代码:
local origin = 10000
function Util.BFS(fpIdx)
local visited = {}
local Q = {}
local firstNode = BFSNode.new(nil, fpIdx)
Q[#Q + 1] = firstNode
visited[fpIdx] = firstNode
while #Q > 0 do
local node = Q[1]
table.remove(Q, 1)
local v = graph[node.ID]
for i=1, #v.children do
local id = v.children[i]
if id == origin then
local bfsNode = BFSNode.new(node, id)
bfsNode:Log()
return bfsNode:GetPath()
end
if not visited[id] then
local bfsNode = BFSNode.new(node, id)
visited[id] = bfsNode
Q[#Q + 1] = bfsNode
end
end
end
return nil
end
一、第一次优化
由于我自作聪明,为了提供Log和GetPath这些方法。将节点包装成了一个“BFSNode类”的形式,事实上是存在了一个table内。但是这部分的内存开销和CPU耗时都是非常大的,第一次优化主要就是将这个地方简化了。简化的代码应该是大家实现BFS算法的常用版本了,CPU耗时和内存开销都有所下降了。优化后性能数据如下:
local origin = 10000
local visited = {}
local queue = {}
local remove = table.removoe
local node
local id = 0
function Util.BFS(fpIdx)
visited = {}
queue = {}
queue[#queue + 1] = fpIdx
visited[fpIdx] = -1
while #queue > 0 do
node = remove(queue, 1)
local v = graph[node]
for i=1, #v.children do
id = v.children[i]
if id == origin then
return Util.GetPath(visited, id, node)
end
if not visited[id] then
visited[id] = node
Q[#Q + 1] = id
end
end
end
return nil
end
function Util.GetPath(visited, targetIdx, parentIdx)
local path = { targetIdx }
while parentIdx > 0 do
path[#path + 1] = parentIdx
parentIdx = visited[parentIdx]
end
return path
end
二、第二次优化
第一次优化后,CPU平均耗时1ms,平均内存开销1.4KB都处于可接受的范围了,但是这个代码还是有优化空间的。因为上面代码中visited没有得到复用,我们可以用一段简单的代码复用visited。这次优化做到了773次寻路总内存开销在740KB,visited和Q的开销约为50KB,其余的约700KB内存全部用于构造Path数组,此外没有内存浪费了。如果还需要优化的话就比较难了,不是一些简单的代码能实现的。而对于我们实际应用中,优化到这种程度已经完全够用了。优化后的代码和数据如下:
local noneIdx = 0
local invaildIdx = -1
local origin = 10000
local node
local id = 0
local g = graph
local GetPath = Util.GetPath
local ReuseTable = Util.ReuseTable
local head = 0
local last = 1
function Util.BFS(fpIdx)
head = 0
last = 1
Q[last] = fpIdx
visited[fpIdx] = noneIdx
while last > head do
head = head + 1
node = Q[head]
local v = g[node]
for i=1, #v.children do
id = v.children[i]
if id == origin then
local path = GetPath(visited, id, node)
ReuseTable(visited)
return path
end
if not visited[id] or visited[id] == invaildIdx then
visited[id] = node
last = last + 1
Q[last] = id
end
end
end
ReuseTable(visited)
return nil
end
function Util.GetPath(visited, targetIdx, parentIdx)
local path = { targetIdx }
while parentIdx > 0 do
path[#path + 1] = parentIdx
parentIdx = visited[parentIdx]
end
return path
end
function Util.ReuseTable(t)
for k,_ in pairs(t) do
t[k] = invaildIdx
end
end
三、了解SLua和C#交互
上面的优化示例局限于Lua的写法和用法层面,虽然这是项目中常见的一类优化点,但是我们的Unity项目中,Lua优化还有另一个大头——Lua和C#交互。而要优化这部分,就先要明白Lua和C#交互时发生了什么。因为笔者用的是SLua,所以这里分析Lua和C#交互就以SLua为例了。其中obj为Lua持有的一个C#的GameObject对象,当我们执行以下代码的时候,就产生了两次Lua和C#交互。
local pos = obj.transform.position
这次Lua和C#交互的过程中,全部的流程如上表。简述一下流程就是:
1)取得元表中存储的C#函数指针
2)调用C#函数
3)返回结果
以我的经验来说,LuaCPU性能往往是和内存的开辟密不可分的。所以我们关注的重点在第三步,怎么返回结果的。SLua有一个缓存机制,已经返回过的对象会缓存在一个Map中,并且有一个唯一的索引作为Key。返回的对象会先在C#的Map中查找,如果找到了则返回这个索引。然后用这个索引去Lua的Table中查找对应的值,这个值就是最后返回给Lua的值。这个值是一个Table,其中的元表包含了所有导出的C#函数。而值类型,因为它性质的特殊,每次返回都会新生成一个索引。也就是C#里多缓存一次,Lua里多缓存一个Table。所以从Lua中访问C#中的值类型时,要注意Lua内存的开销。除去常见的Vector2/3/4、Quaternion、Color等常用的值类型做了特殊处理,不经过缓存,其他的值类型都要注意这一点。
不仅是取值,还有设值的时候也要非常小心,上面提到的我们隔壁项目组遇到的问题就类似下面这行代码,在每帧调用的Update里创建LuaVector3。因为调用这个函数的时候,C#中取LuaVector3是分别取的这个Table下标为1\2\3的三个值包装为C#的Vector3,然后设给position。所以当设完值以后这个LuaVector3由于没有任何人引用(虽然看起来是复制给了一个对象),就会被回收掉,每一帧都会新建一个Table然后回收一个Table。
function Test:Update()
obj.transform.position = LuaVector3.New(0, 0, 0)
end
这是侑虎科技第299篇原创文章,感谢作者舒航供稿,欢迎转发分享,未经作者授权请勿转载。当然,如果您有任何独到的见解或者发现也欢迎联系我们,一起探讨。(QQ群:793972859)
作者也是U Sparkle活动参与者,UWA欢迎更多开发朋友加入U Sparkle开发者计划,这个舞台有你更精彩!