上一讲我们讲解了如何通过优化Ruby代码来提升我们的Rails应用性能，这一讲，让我们更深入一些，先看看Ruby的内存管理和垃圾回收机制。
首先，由于Ruby最初的设计目标是成为像Perl那样的批处理语言，因此它的内存管理机制并没有针对Rails这样的需要长期运行的服务端程序进行最优化，有些地方甚至是背道而驰：
- Rails的内存管理策略是尽量减少内存占用
- 标记和清除算法十分简单
- 使用malloc来分配连续的内存块（Ruby heap）
- 复杂的数据结构
- C扩展十分容易编写，但是当前的C接口很难实现generational GC（Ruby2有可能）
Ruby的垃圾回收机制对于Rails也不是最优的，由于Ruby的AST（抽象语法树）存储在堆上，并且在每次GC时都会被扫描一遍，而这恰恰是Rails中最大的一块非垃圾区，也就是说，GC对于Rails做的大部分工作都是做无用功。
并且，Ruby的清除算法依赖于堆的大小，而不是当前非垃圾区的大小，但是堆的增长存在一定限制，只有当进行GC后，当前的freelist < FREE_MIN，堆才会增加，gc.c中定义的增加值为4096，这对于Rails来说明显太小了，堆应该至少能够容纳20万个对象。
要提高Ruby GC的性能，可以在Rails dispatcher中添加如下语句：
# excerpt from dispatch. fcgi
RailsFCGIHandler.process! nil, 50
这句话将禁止Ruby GC运行，在处理50个请求后再启用GC，但是这个方法存在一个问题，它没法区分小请求和大请求，这有可能会导致：
- 堆变的过大
- 小页面的性能会受损
- Ruby will still deallocate heap blocks if empty after GC（这句不是很理解，上原文）
除了控制GC的运行时机，也可以通过修改GC的参数来提升性能，但需要先给GC打补丁，下载最新的railsbench，打上rubygc.patch补丁，然后重新编译并安装Ruby，就可以通过以下参数对GC进行调整了：
- RUBY_HEAP_MIN_SLOTS, 初始堆大小，默认10000
- RUBY HEAP FREE MIN，GC后可用的heap slot的最小值，默认4096
- RUBY GC MALLOC LIMIT，允许不触发GC而分配的C数据结构的最大值（字节为单位），默认8,000,000
我们的推荐值为：
RUBY_HEAP_MIN_SLOTS = 600000
RUBY_GC_MALLOC_LIMIT = 60000000
RUBY_HEAP_FREE_MIN = 100000
如果你进行基准测试的话，就会发现性能提高不少。
最后，我们再讲讲模板优化，对于许多在编译时就知道结果的helper方法，完全没有必要在每次处理请求时都进行解析，比如：
<%= end_form_tag %> ===> </form>
这纯粹就是浪费时间，还有我们前面提到的link_to，因此，如果我们可以在敲代码时确定这个helper的输出，那么最好直接写出结果。
另外，还可以使用Ryan Davis的ParseTree和ruby2ruby来获取ActionView的render方法的AST，并进行模板终极优化：
- 展开所有helper方法
- 去除不会调用到的代码
- 去除不会用到的变量（以及partials）
- 合并hash
- 替换常量
- 替换结果已确定的方法调用
- 替换符号
然后使用eval将新的AST编译入优化后的render方法。
好了，到这里，这一系列的文章就结束了，附录中还有一些性能测试的数据和配置信息，就不一一列举了，感兴趣的可以下载原文查看。
