Lua Performance Optimization Techniques (i): Preface _lua

As in all other programming languages, in Lua, we should still follow the following two proverbs about program optimization:

Principle 1: Do not optimize.
Principle 2: Do not optimize for the time being (for experts).

These two principles are particularly meaningful for LUA programming, where Lua stands out from the scripting language for its performance.

Of course, we all know that performance is an important factor to consider in programming, and it is no coincidence that a number of time complexity algorithms are considered intractable problems. If the calculation comes too late, it is a useless result. As a result, every good programmer should always balance the resources that are spent in optimizing the code and the resources that are saved when the code is executed.

The first question a good programmer has to ask about code optimization is: "Does this program need to be optimized?" "If the answer is yes, the second question is:" Where is the optimization? ”

To answer these two questions, we need to set some standards. No optimizations should be done before performing an effective performance assessment. The difference between experienced programmers and beginners is not that the former is good at pointing out the main performance cost of a program, but the former knows that he is not good at it.

A few years ago, Noemi Rodriguez and I developed a prototype of a CORBA orb[2 for Lua, which later evolved into oil. As the first prototype, the goal of our implementation is simplicity. To prevent dependency on the additional C function library, this prototype uses a small number of arithmetic to separate bytes (converted to 256) and does not support floating-point values when serializing integers. Since the CORBA view string is a sequence of characters, our Orb initially converts the LUA string into a sequence of characters (that is, a LUA table) and equates it with other sequences.

When we finished this prototype, we compared its performance to a professional orb that was implemented using C + +. Since our orb was implemented using LUA, we expected to tolerate it slower, but the contrast showed that it was slowing too much and we were very disappointed. At first we attributed the responsibility to the Lua itself; We later doubted that the problem was in the operations that required serialization of integers. We used a very simple performance analyzer (Profiler), which is not much different from the one described in the LUA programming [3] 23rd chapter. To our surprise, integer serialization does not significantly slow down the program because there are not too many integers to serialize, but serialization of strings requires a lot of responsibility for low performance. In fact, each CORBA message contains several strings, even if we do not explicitly manipulate the string. and serializing each string is a very expensive job because it needs to create a new table, fill it with a separate character, and then serialize the entire sequence, which needs to serialize each character sequentially. Once we implement string serialization as a special case (rather than through a common serialization process), the performance of the entire program is significantly improved. We just added a few lines of code, the program's performance and C + + implementation of that version of a spell [4].

Therefore, we should always perform performance testing before optimizing performance. By testing, you can learn what to optimize, and then test again after tuning to make sure that our optimization work does bring performance improvements.

Once you decide you have to optimize your LUA code, this article will probably help. This article describes some of the optimization methods, mainly showing how to do it more slowly in Lua and how to do it faster. Here, I will not discuss some generic optimization techniques, such as optimization algorithms, and so on--of course, you should master and use these skills, there are many other places to understand this content. This article focuses on some of the optimization techniques specifically for LUA, while I continue to test the time and space performance of the applet. If not specifically noted, all tests are performed on a Pentium IV 2.9GHz, 1GB memory, a machine running Ubuntu 7.10, Lua 5.1.1. I often give actual measurements (for example, 7 seconds), but this only makes sense when compared to other measurements. And when I say that a program is X percent faster than the other, means that the former consumes X percent less than the latter (that is, a program that is 100% faster than another program does not require time); When I say one program is slower than the other, it says that the latter is faster than x percent (meaning, 50% slower than the other program). The program consumes twice times as much time as the former.