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, which stands out among scripting languages because of its performance.
Of course, we all know that performance is an important factor to consider in programming. It is no accident that algorithms with exponential time complexity will be considered a thorny problem. If the result of the calculation comes too late, it is useless. Therefore, every good programmer should always balance the resources spent in optimizing the code and the resources saved in executing the code.
The first question a good programmer should ask about code optimization is: “does this program need to be optimized?” If (only at this point) the answer is yes, the second question is: “where to optimize?”
We need to set some standards and answer two questions. No optimization should be done before effective performance evaluation. 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 that the former knows he is not good at doing it.
A few years ago, Noemi Rodriguez and I developed a CORBA orb  Prototype for Lua, which later evolved into oil. As the first prototype, our goal is simplicity. In order to prevent dependence on additional C function libraries, this prototype uses a small number of four operations to separate each byte when serializing integers (converted to base 256), and does not support floating-point values. Since CORBA regards strings as character sequences, our orb initially converts Lua strings into a character sequence (that is, a Lua table) and treats them as equivalent to other sequences.
When we finished the prototype, we compared its performance with a professional orb implemented in C + +. Since our orb is implemented using Lua, we can tolerate it to be slower, but the comparison results show that it is too slow, which makes us very disappointed. At the beginning, we attributed the responsibility to Lua itself; Later, we suspected that the problem lies in the operations that need to serialize integers. We use a very simple profiler, which is not much different from the one described in Chapter 23 of lua programming. To our surprise, integer serialization did not significantly slow down the program, because there were not many integers to serialize; Instead, serializing strings takes a lot of responsibility for low performance. In fact, every CORBA message contains several strings, even if we do not explicitly manipulate strings. Moreover, serializing each string is a huge performance overhead, because it needs to create a new table and fill it with separate characters; The entire sequence is then serialized, where each character needs to be serialized in turn. Once we re implement string serialization as a special case (rather than through the general serialization process), the performance of the whole program has been significantly improved. We just added a few lines of code, and the performance of the program is as good as the version implemented in C + + .
Therefore, we should always conduct performance testing before optimizing performance. Only through testing can we know what to optimize; Test again after optimization to confirm that our optimization work has indeed brought performance improvement.
Once you decide that you must optimize your Lua code, this article may be helpful. This article describes some optimization methods, mainly showing how to do it slower and faster in Lua. Here, I won’t discuss some general optimization techniques, such as optimization algorithms, etc. – of course, you should master and use these techniques, and there are many other places to learn about them. This article focuses on some optimization techniques specifically for Lua. At the same time, I will continue to test the temporal and spatial performance of applets. Unless otherwise specified, all tests are conducted on a Pentium IV 2.9ghz, 1GB memory machine running Ubuntu 7.10 and Lua 5.1.1. I often give actual measurement results (for example, 7 seconds), but this only makes sense when compared with other measurement data. When I say that one program is x% faster than another, it means that the former consumes x% less time than the latter (that is, the program running 100% faster than the other program does not need time); When I say that one program is x% slower than another, I mean that the latter is x% faster than the former (that is, a program that is 50% slower than the other program takes twice as long as the former).