XLua优化

已经从上海回北京一个星期了,也都已经忙好安顿了下来,回想了一下项目后期的一些优化举措,现在写出来,留个念想

这是我很少见的没有代码的博客吧,或许以后会更多

--------------------------------------------不---------割-----------------------------------------------------------------------------

1,给table添加元素时,tab[#tab+1]=a比table.insert(tab,a)效率高,远比table.insert(tab,1,a)效率高
2,在循环内创建变量和循环外创建变量的效率取决于创建代价和跨域代价的对比,一般情况根据经验选择
3,以局部变量代替多次使用的外部变量(xx.xx之类)
4,减少函数调用可以很大的提高效率,但会降低代码的可读性,根据经验选择
5,提前声明table大小可以很大提高效率,尽量做到!
6,string.format比…效率低,但可读性会很高,个人感觉没必要,对我来说都一样
7,在大字符串连接中,尽量避免…,用table来模拟buffer,然后用contact来获得最终字符串
8,判断数组表是否为空时,一般情况用#tab>0就行,如果tab长度特别大,用next(tab)的效率才更高
9,3R原则:
(Reducing):避免创建新对象和节约内存,如果程序中用了太多的表,可以考虑换一种数据结构
(Reusing)如果无法避免创建新对象,则需要考虑重用旧对象
(Recyling)Lua的垃圾回收机制是一个增量运行的机制,也就是说回收分为许多小步骤(增量的)来运行,.频繁的垃圾回收可能会降低程序的运行效率,可以通过Lua的collectgarbage函数来控制垃圾回收
10,能用local的尽量用local,能写在同一脚本内部的变量,尽量不跨脚本调用,单一职责原则

常见泄露:C#代理
一般情况下遇得到的比较多的泄露就是C#代理,如果把Lua函数注册给C#的代理,name这个Lua匿名函数将不能正确的被LuaGC了,也就是泄露了,改进方法就是不把Lua匿名函数注册给C#代理,这样的话,每一段时间C#都会主动Dispose.

常住内存优化:(消除配置文件中冗余数据,达到压缩和优化数据存储)
Lua作为一个极为精简的嵌入型脚本语言,一般用来实现游戏的上层业务逻辑,或者借助其本身的灵活简单的数据表达能力来用于存储(配置文件).
配置文件一般由程序员提供的导出工具来给策划进行维护(嘿嘿嘿,反正我是这么干的,让他们烦恼去吧),然后把Excel的表格数据导出为游戏可以直接读取的Lua源码.这些源码文件以Lua table的形式存储与Excel等价的数据一般来说类似二维数组或者字典的概念,一个Key对应一组子数据,如果配置文件的数据过大,或者有哦荣誉的无用户数,name就会严重的影响加载速度和增大内存占用量.
一般来说大量的重复数据或者待变没有意义的空值,大量的中文字符串需要后期本地处理的,很多复合型数据内容是一样的,针对于上面一句话制定方案:对于Excel中的一列,出现次数最多的值认定为默认值,然后把它从Lua表中剔除掉,然后利用Metable机制实现全局默认值存储.对于中文字符串,替换为一个唯一的ID表示,写回到Lua表中,读取的时候加上相应的查找替换.对于一些复杂的字标或者数组,左为宜华替换处理,替换后协会到原始数据中.,这些坐的都是唯一化处理,所以对Lua标的要求必须是可读的.因为多出引用的字标已经被替换成为一个变量,这些变量是一local
的形式存储在作用域的,由于Lua本身的限制,一个作用域内能存放的最大local变量的个数是200个,所以超过的部分会被放入一个临时数组中,初始化的时候需要额外的查表,可能会多一些开销,但目前可以接受.
一般来说配置表文件优化后,只有不到之前的一半大小了,可以极大地提高加载时间和内存占用.