第十三章：速度.pdfVIP

第⼗三章：速度 Lisp 实际上是两种语⾔：⼀种能写出快速执⾏的程序，⼀种则能让你快速的写出程 序。 在程序开发的早期阶 ，你可以为了开发上的便捷舍弃程序的执⾏速度。⼀旦程 序的结构开始固化，你就可以精炼其中的关键部分以使得它们执⾏的更快。 由于各个 Common Lisp 实现间的差异，很难针对优化给出通⽤的建议。在⼀个实现上 使程序变快的修改也许在另⼀个实现上会使得程序变慢。这是难免的事⼉。越强⼤的 语⾔，离机器底层就越远，离机器底层越远，语⾔的不同实现沿着不同路径趋向它的 可能性就越⼤。因此，即便有⼀些技巧⼏乎⼀定能够让程序运⾏的更快，本章的⽬的 也只是建议⽽不是规定。 13.1 瓶颈规则 (The Bottleneck Rule) 13.2 编译 (Compilation) 13.3 类型声明 (Type Declarations) 13.4 避免垃圾 (Gar age Avoidance) 13.5 ⽰例: 存储池 (Example: Pools) 13.6 快速操作符 (Fast Operators) 13.7 ⼆阶 开发 (Two-Phase Development) Chapter 13 总结 (Summary) Chapter 13 练习 (Exercises) 13.1 瓶颈规则 (The Bottleneck Rule) 不管是什么实现，关于优化都可以整理出三点规则：它应该关注瓶颈，它不应该开始 的太早，它应该始于算法。 也许关于优化最重要的事情就是要意识到，程序中的⼤部分执⾏时间都是被少数瓶颈 所消耗掉的。 正如⾼德纳所说，“在⼀个与 I/O ⽆关 (Non-I/O ound) 的程序中，⼤部 分的运⾏时间集中在⼤概 3% 的源代码中。” λ 优化程序的这⼀部分将会使得它的运⾏ 速度明显的提升；相反，优化程序的其他部分则是在浪费时间。 因此，优化程序时关键的第⼀步就是找到瓶颈。许多 Lisp 实现都提供性能分析器 (profiler) 来监视程序的运⾏并报告每⼀部分所花费的时间量。 为了写出最为⾼效的代 码，性能分析器⾮常重要，甚⾄是必不可少的。 如果你所使⽤的 Lisp 实现带有性能 分析器，那么请在进⾏优化时使⽤它。另⼀⽅⾯，如果实现没有提供性能分析器的 话，那么你就不得不通过猜测来寻找瓶颈，⽽且这种猜测往往都是错的 ！ 瓶颈规则的⼀个推论是，不应该在程序的初期花费太多的精⼒在优化上。⾼德纳对此 深信不疑：“过早的优化是⼀切 (⾄少是⼤多数) 问题的源头。” λ 在刚开始写程序的时 候，通常很难看清真正的瓶颈在哪，如果这个时候进⾏优化，你很可能是在浪费时 间。优化也会使程序的修改变得更加困难，边写程序边优化就像是在⽤风⼲⾮常快的 颜料来画画⼀样。 在适当的时候做适当的事情，可以让你写出更优秀的程序。 Lisp 的⼀个优点就是能让 你⽤两种不同的⼯作⽅式来进⾏开发：很快地写出运⾏较慢的代码，或者，放慢写程 序的速度，精雕细琢，从⽽得出运⾏得较快的代码。 在程序开发的初期阶 ，⼯作通常在第⼀种模式下进⾏，只有当性能成为问题的时 候，才切换到第⼆种模式。 对于⾮常底层的语⾔，⽐如汇编，你必须优化程序的每⼀ ⾏。但这么做会浪费你⼤部分的精⼒，因为瓶颈仅仅是其中很⼩的那部分代码。⼀个 更加抽象的语⾔能够让你把主要精⼒集中在瓶颈上， 达到事半功倍的效果。 当真正开始优化的时候，还必须从最顶端⼊⼿。 在使⽤各种低层次的编码技巧 (low- level coding tricks) 之前，请先确保你已经使⽤了最为⾼效的算法。 这么做的潜在好处 相当⼤ ── 甚⾄可能⼤到你都不再需要玩那些奇淫技巧。 当然本规则还是要和前⼀ 个规则保持平衡。 有些时候，关于算法的决策必须尽早进⾏。 13.2 编译 (Compilation) 有五个参数可以控制代码的编译⽅式： sp eed (速度)代表编译器产⽣代码的速 度； comp ilation-sp eed (编译速度)代表程序被编译的速度； saf ety (安全) 代表要对⽬标 代码进⾏错误检查的数量； sp ace (空间)代表⽬标代码的⼤⼩和内存需求量；最 后， debug (调试)代表为了调试⽽保留的信息量。 交互与解释 (INTERACTIVE VS. INTERPRETED) Lisp 是⼀种交互式语⾔ (Interactive La