Lua Performance Tips - Lua性能（方面）的技巧

----------------------- Page 1-----------------------15


                Lua Performance Tips
                Lua性能（方面）的技巧

                                               Roberto Ierusalimschy

    MENU
Basic facts
基本事实
About tables
关于表
About Strings
关于字符串
Reduce, reuse, recycle
简化，重用，再生
Final remarks
结语


In Lua, as in any other programming language, we should always follow the two maxims of program optimization:
同任何其他编程语言一样，在Lua中，我们应该始终恪守程序优化的两条箴言：

Rule #1: Don't do it.
准则 1：不要优化。
Rule #2: Don't do it yet.(for experts only)
准则 2：还是不要优化。（仅限于专家）

Those rules are particularly relevant when programming in Lua. Lua is famous for its performance, and it deserves its reputation among scripting languages.
当进行Lua编程时，那些准则尤其适用。在脚本语言中，Lua因其性能而著名，而且当得起对它的赞誉。

    Nevertheless, we all know that performance is a key ingredient of programming. It is not by chance that problems with exponential time complexity are called intractable. A too late result is a useless result. So, every good programmer should always balance the costs from spending resources to optimize a piece of code against the gains of saving resources when running that code.
    然而，我们都知道性能是编程的一个关键因素。具有指数时间复杂度的问题被视为棘手并非偶然。太迟的结果是没用的结果。所以，每个好的程序员都应该始终对花费资源优化一块代码的代价以及那块代码运行时节约的资源带来的收益进行平衡。

    The first question regarding optimization a good programmer always asks is: "Does the program needs to be optimized?" If the answer is positive (but only then), the second question should be: "Where?"
    好的程序员问的关于优化的第一个问题总是：“程序需要优化吗？”如果答案是肯定的（仅当此时），第二个问题应该是：“在哪儿（做优化）？”

    To answer both questions we need some instrumentation. We should not try to optimize software without proper measurements. The difference between experienced programmers and novices is not that experienced programmers are better at spotting where a program may be wasting its time: The difference is that experienced programmers know they are not good at that task.
    要回答这两个问题，我们需要一些探测设备。我们不应该没做适当的测量就尝试优化软件。有经验的程序员和新手的区别并非前者善于定位程序费时的部位：区别是有经验的程序员知道他们不擅长那个任务。

    A few years ago, Noemi Rodriguez and I developed a prototype for a CORBA ORB (Object Request Broker) in Lua, which later evolved into OiL (Orb in Lua). As a first prototype, the implementation aimed at simplicity. To avoid
    几年前，Noemi Rodriguez和用Lua我开发了一个CORBA ORB（Object Request Broker，对象请求代理），它后来演变成了OiL（Orb in Lua）。作为第一原型，实现力求简明。为了避免


----------------------- Page 2-----------------------16


the need for extra C libraries, the prototype serialized integers using a few arithmetic operations to isolate each byte (conversion to base 256). It did not support floating-point values. Because CORBA handles strings as sequences of characters, our ORB first converted Lua strings into a sequence (that is, a Lua table) of characters and then handled the result like any other sequence.
对额外的C库的需要，该原型用一些算术操作分离每个字节（转化为以256为基数）来序列化整数。它不支持浮点值。因为CORBA把字符串作为字符序列来处理，我们的ORB首先把Lua字符串转为一个字符序列（即一个Lua表），然后同任何其他序列一样处理这些结果。

    When we finished that first prototype, we compared its performance against a professional ORB implemented in C++. We expected our ORB to be somewhat slower, as it was implemented in Lua, but we were disappointed by how much slower it was. At first, we just laid the blame on Lua. Later, we suspected that the culprit could be all those operations needed to serialize each number. So, we decided to run the program under a profiler. We used a very simple profiler, not unlike the one described in Chapter 23 of Programming in Lua. The profiler results shocked us. Against our gut feelings, the serialization of numbers had no measurable impact on the performance, among other reasons because there were not that many numbers to serialize. The serialization of strings, however, was responsible for a huge part of the total time. Practically every CORBA message has several strings, even when we are not manipulating strings explicitly: object references, method names, and some other internal values are all coded as strings. And the serialization of each string was an expensive operation, because it needed to create a new table, fill it with each individual character, and then serialize the resulting sequence, which involved serializing each character one by one. Once we reimplemented the serialization of strings as a special case (instead of using the generic code for sequences), we got a respectable speed up. With just a few extra lines of code, the performance of your implementation was comparable to the C++ implementation.1
    当完成了那个第一原型，我们拿它的性能跟C++实现的专业ORB做了比较。本以为我们的ORB只会稍微慢一些，因为是用Lua实现的，但是实际有多慢让我们失望了。起初，我们归咎于Lua。后来，我们怀疑原因可能是序列化每个数字所需的所有那些操作。所以，我们决定在profiler的监控下运行程序。我们用了一个非常简易的profiler，与Programming in Lua的第23章中描述的那个没有什么不同。profiler结果让我们震惊。与我们的直觉相反，在其他原因中，数字的序列化对性能没有可度量的影响，因为并没有多少数字需要序列化。然而，字符串的序列化构成总体时间的极大部分。实际上每个CORBA消息都有一些字符串，即使当我们不显式地操作字符串时：对象引用，方法名，以及其他的一些内部值都被编码为字符串。而且每个字符串的序列化是代价高昂的操作，因为它需要创建一个新表，用每个单独的字符填充，然后序列化该合成的序列——该操作涉及连续序列化每个字符。一旦把字符串的序列化作为特殊情形（不是用序列的通用代码）重新实现后，我们获得了可观的速度提升。只是几行额外的代码，你的实现的性能就能与C++的实现相当。1

    So, we should always measure when optimizing a program for performance. Measure before, to know where to optimize. And measure after, to know whether the "optimization" actually improved our code.
    所以，当优化程序性能时，我们应该总是进行测量。（在优化）之前测量来分辨在哪儿优化。并且（在优化）之后测量来了解“优化”是否真的改善了我们的代码。

    Once you decide that you really must optimize your Lua code, this text may help you about how to optimize it, mainly by showing what is slow and what is fast in Lua. I will not discuss here general techniques for optimization, such as better algorithms. Of course you should know and use those techniques, but there are several other places where you can learn them. In this article I will discuss only techniques that are particular to Lua. Along the article, I will constantly measure the time and space performance of small programs. Unless stated otherwise, I do all measures on a Pentium IV 2.9 GHz with 1 GB of main memory, running Ubuntu 7.10, Lua 5.1.1. Frequently I give actual measures (e.g., 7 seconds), but what is relevant is the relationship between different measures. When I say that a program is "X% times faster" than another it means that it runs in X% less time. (A program 100% faster would take no time to run.) When I say that a program is "X% times slower" than another I mean that the other is X% faster. (A program 50% slower means that it takes twice the time.)
    一旦你决定确实应该优化你得Lua代码，本文可在如何优化方面帮助你，主要是通过展示Lua中什么是慢的以及什么是块的。这儿我不会讨论优化的通用技术，比如更好的算法。当然，你应该知道并使用那些技术，但是你可在其他地方了解它们。本文中我将只讨论特定于Lua的技术。纵览本文，我将坚持度量小型程序的时间和空间性能。除非另作说明，我在一台Pentium IV 2.9 GHz、带1GB主存、运行Ubuntu 7.10和Lua 5.1.1（的机器）上做全部量度。我常常是给出实际测量值（比如7秒），除非适用于不同测量的关系（的情况）。当我说一个程序比另一个“快X%倍”时是指它的运行少用X%的时间。（快100%的程序的运行不花费任何时间）当我说一个程序比另一个“慢X%倍”时是指另一个快X%。（程序慢50%意味着它花费两倍时间。）

-----------------------
   1 Of course our implementation was still slower, but not by an order of magnitude.
     当然，我们的实现仍然慢一些，但不是按照数量级（计算）了。