函数式语言：我的性能没问题

[quote]lichray 将用几天的时间写完本文系列文章的全部，[color=red]剩下的文章将会发布在新建的 [url="http://wfp.group.iteye.com/"]函数式编程の道 [/url] 圈子上[/color]。这些文章将并非是从编译原理的角度来探讨函数式编程语言的文章。本文只会浅尝辄止地覆盖函数式编程语言的编译、解释优化手段，并试图让大家相信：使用函数式编程语言/风格，获得的只是表达能力上的大幅提升，而程序性能几乎不会下降。
PS: 文章中部分内容可以在《现代编译原理》这本书中找到。
[/quote]

[b][size=12]一. 内存分配优化[/size][/b]

[b]1. 高阶函数[/b]
* 针对不纯的函数式编程语言：
不纯的函数式编程语言其实也就是比普通的命令式语言多了这个高阶函数罢了，但性能会造成下降：因为函数必须能具有普通变量的可操作性，比如作参数、返回值，函数必须作为数据的一种、被分配在堆上而不是栈上。
在处理在堆上分配函数方面，函数的创建、查找对于现在的算法来说已不是问题，关键是处理重复的函数——数据重复一般是无所谓，因为创建速度太快，而函数就不同了；如果在一个循环中创建函数，那岂不是要了函数式编程语言的命？
[code]
for (var i = 0; i < 10; i++) {
var f = function (a) {
return a * a
}
print(f(i))
}
[/code]
对于“相同的函数”，有必要只保留一个。
如果两个函数是“相同”的，需要满足下面两个定义中的一个：
[list]
[*]二者从程序的源代码文本的同一处获取其函数体
[*]在使用 eval() 函数从产生程序时，二者从其参数的同一处获取其函数体
[/list]
这样简单的定义已经能够处理大部分情况了（比如上面那个例程）。

* 针对纯函数式编程语言：
纯函数式编程语言的要求更加严格，决不允许出现赋值，但优化起来可以更“放心”。例如，如果编译/解释该语言需要用到中间代码，下面的优化就可以办到：
[list]
[*]进入执行上下文，重命名内部绑定的变量，用中间代码翻译所有函数体，若存在中间代码相同的函数，认为它们是同一个函数
[*]在使用 eval() 函数从产生程序时……（略）
[/list]
这样一来，重复说明函数体相同（或只有内部绑定的变量命名不同）的函数将被优化——因为变量的绑定不会改变，不用担心调用两个函数造成的“结果”不同。

[b]2. 词法作用域[/b]
对于支持词法作用域（套嵌函数）的语言来说，因为函数拥有有执行上下文，函数还必须“记住”自己是在哪儿被调用的，在那儿还声明了什么变量，因此需要一个“环境”，雪上加霜。
一些书上会这样描述一个词法作用域查找变量绑定位置的过程：
[list=1]
[*]查找本级作用域是否包含该变量的绑定
[*]如果 Result(1) 为假，转到 Step4
[*]返回本级作用域中该变量的绑定
[*]如果本级作用域是全局作用域（顶层），报错
[*]对上级（调用环境）作用域应用 Step1
[/list]
言下之意，函数都是被保存在一个链表中的指针所指向的，然后就像访问链表那样查找本级、上级……然后算法复杂度为 O(n)。但你觉得这可能吗？看看下面的 Scheme 代码：
[code]
(define (fact n)
(if (= n 0)
1
(* n (fact (- n 1)))))
[/code]
完了，要创建深度为 n 的链表啦，回忆一下 C 里面的 malloc() 的效率，一般 profile 出来的罪魁祸首就是它，不觉得毛骨悚然吗？
没有一个真正的函数式编程语言实现是在链表上分配函数的，函数被分配在哈希表中的可能性其实也不大（因为缺乏层次搜索能力），一般都是在经过特殊优化的二叉树上分配。真正的变量搜索算法也不可能那么傻，一般只是把原有的符号表“立体化”。此外，通过先进的活跃性分析技术，更有可能被重复使用的函数所需的逃逸变量将更容易被找到。

(To be continued)