【 以下文字转载自 New_Board 讨论区 】
【 原文由 heyuzi 所发表 】
如何将 LPC 程式最佳化
(MudOS 0.9.x 版)
作者: Luke Mewburn
版本: 1.2
日期: 930321
翻译: Devianth , elon@eastern.stories
      (10/29/94)
0. 简介
我写这篇文章的原因是我注意到 LPmud 越来越倾向复杂化及玩家驱动的功能.
这是好现象, 但因为 LPC 运作的方法 (一次只解译一部份的程式) 写不好的程
式码不但会使的整个 mud 慢下来, 也会使在 mud 上的玩家感到 'lag'.
 
因为如此, 我决定去找出方法将一些常用的工作写成有效率的程式并记录下来
以供参考. 我假设读者已有一些 C 或 LPC 的程式经验. 但是, 如果你是新手,
我依然建议你将本文读完因才能在一开始就学到正确的程式写法.
虽然我的研究是关於 MudOS 0.9 的 driver, 但许多经验还是能在其它 LP v3
型的 driver 下使用. 但这并不保证这里所讲的在非 MudOS driver 下是完全
正确的, (比方说 Amylaar 的 3.2@22 driver), 因为各 driver 程式码已经
有相当大的差异了.
以下的程式码, 我们将假设这些定义:
int i, j, max, bitfield;
object *list;
string *arr, name;
LPC, 像 C 一样, 有支援 '动态配置'. 也就是 driver 只有在需要
时才会将记忆体分给要用的运算 (完成後会收回). 跟 C 不同的是, LPC 会自动
地在你使用完後收回分配的记忆体 (i.e. 当没有 LPC 程试码在使用时) - 又叫
'清除收集'. 字串 (string), 阵列 (array) 和 mapping 都是'动态'处理的.
虽然 '动态配置' 在结构化程式里非常有用, 但相对的它也使用了非
常多的 CPU 时间. 本文的目地之一就是要教你如何正确的运用 '动态配置'
的好处而不要浪费了这项功能.
 
1. GENERAL POINTS
在我开始教你如何始某段程式码加速运作前, 我提出以下一些关於电脑程式写作
的公理:
第一条, '电脑花 80% 的时间执行 20% 的程式' ('80% of the time spent
executing an algorithm is in 20% of the code'), 或是所谓的 '80/20' 法
则. (有些说法是 75/25 或 90/10).  这个经证实的事实可以有效的帮助你写
LPC 不要花太多时间试著将你所有的 LPC 程试码最佳化, 你不会有那麽多的时
间. 将精神放在一些较常用, 执行次数较多的区段, 如 for-loops 等.
第二是, 如何选用正确的 algorithm. 大多数的时间, 当一个简单的 algorithm
就足够时, 人们会选择一个复杂 algorithm, 特别是当程式处理少数资料时, 简单
的 algorithm 通常比较有效率. 要能在简化及效率上作一番取舍.
因为大部份的 driver 都没有对 LPC 码作最佳化的功能 (比方说重写 expression
或回圈 strength-reduction), 你能帮的忙就是有智慧的写自己的程式码.
一个加速的方法是将一个共用的常数/函式移到回圈或回圈测试之外, 并使用一
个暂时的变数. 最长见的就是在 while/for condition (q.v) 时使用 'sizeof(arr)'
在其它状况下, 有可能某个函式每次都会在回圈里被呼叫, 但那个函式每次都会

传回一个相同的值 - 如果真是这样, 就在回圈以外将这个值设定成一个变数, 并
在回圈内使用这个变数. 例如:
for ( i = 0; i < max; i++)
    if ( list[i] == some_condition )
        do_something_with( list[i], this_player()->query("name") );
假设 "name" 是不变的, 则以下的方法会比较好:
name = this_player()->query("name");
for ( i = 0; i < max; i++)
    if ( list[i] == some_condition )
        do_something_with( list[i], name );
虽然说好的程式格式并不会真的加快编译的速度, 但一个简单好读的程式比较
好修改及 debug. 大多数的人对程式的格式有不同的看法, 所以我在这里也不
会强迫读者使用我的格式, 我只想告诉你, 选择一个你喜欢的