Erlang-China

俺喜欢从实例中学习——遵循：“问题-分析-方案-结论”的认知过程。这篇是个小小的尝试，如果效果还不错，后面再去整理几个。杀猫长文，代码满塞，慎入。:D

【问题】

9月23日，Erlang 的 maillist 中，有人发现了这么一篇文章《Erlang Blues》

正如它的标题，这篇文章从批评的眼光，指出了许多作者本人并不喜欢 Erlang 的地方。文章本身的观点姑且不论，但确实是指出了作为一个“普通程序员”看待和评估 Erlang 时必然会留意到的问题。即，按照通常习惯写出来的文件 io 代码，性能很糟糕，比如，下面的代码：

这是一个简单的统计文件行数的程序，在他的 MacBook 上处理一个 1,167,948 行的日志文件，竟然用了 34.165 秒，而相同功能的 ruby 程序只用了 3.036 秒。性能差距有十倍之多，不可谓不大。

这是为什么？莫非 Erlang 的文件 io 系统设计得如此糟糕？且看 Erlang 的社区如何反应此事？

【分析】

Thomas Lindgren (在 XML 处理上，对 Erlang 和 Ruby 有过 10s / xxm 的比对经验)指出：

io:get_line 是在字符串级别处理文件的函数，它的实现非常慢，而 file:read_file 将整个文件读为 binary 则要快得多。

Caoyuan (是的，就是这里的 dcaoyuan ，知名的 ErlyBird 的作者)指出：

这个问题其实并不是关于文件 io 的，测试表明，file:read_file 以 binary 方式读到内存非常快，重要的是在于这个过程需要遍历 binary 数据，遍历整个 200m 的 binary 数据是很耗费时间的一个任务。

他给出了如下的测试程序：

需要说明的是，这个测试程序很总要，它更清晰的“定位”了问题，file:read 并不慢，慢的是对它的处理。另外，后面还有关于这段代码的讨论。

Bob Ippolito (MochWeb库的作者)则指出：

做这件事最显而易见的方法是 spawn 一个 cat 的进程，让 Erlang 的 port 机制来完成这些事情。

他给出了一个例子。(需要 MochWeb_Util)

这个例子提供了一个很好的思路，当我们遇到类似问题的时候，如果暂时不知道怎么解决，我们可以用 port 的方式先绕过问题。不过，这仍然没有解决我们的疑惑——仅用 Erlang 本身，能否很好的处理这类问题？

Ulf Wiger(ErlHive的作者)给出了一个 Erlang 下快速的文件 io 处理方案：

细看之下，这个例子也是用 port 的方式来完成文件 io 的，那么，纯 Erlang 方式下，这个问题是否有办法得到解决呢？

Thomas Lindgren 指出了 dacaoyuan 上面代码中尚有改进余地的地方：

首先，没有必要将 binary 转换成 list ，而是可以直接从 binary 获得一个字节。也就是：

1. travel_bin(Bin) -> travel_bin(Bin, 0).
2. travel_bin(<<>>, ByteCount) -> ByteCount;
3. travel_bin(<<_C:1/binary, Rest/binary>>, ByteCount) ->
4.     travel_bin(Rest, ByteCount + 1).

可以写成：

1. travel_bin(Bin) -> travel_bin(Bin, 0).
2. travel_bin(<<>>, ByteCount) -> ByteCount;
3. travel_bin(<<C, Rest/binary>>, ByteCount) ->
4.     travel_bin(Rest, ByteCount + 1).

这么做的好处是可以避免生成一个单字节的 binary ，每次操作都能在堆上省下几个字节。
其次，象这样来遍历一个 binary 通常不是最好的办法，因为 <> 这一句通常意味着要构造一个新的 binary (Rest，3byte的指针)，这通常不如将其转换为 list (2byte的结构)再处理更高效。
在这个程序结构之上优化，可以一次处理多个字节，如：

1. loop(<<C0,C1,C2,C3,C4,C5,C6,C7, Rest/binary>>) ->
2.    ..., loop(Rest);
3. loop(Small_bin) -> ...

Bjorn Gustavsson (OTP Team)指出：

Thomas Lindgren 的建议在 R11 中是正确的，但在即将到来的 R12 中，可能会导致性能反而下降。因为 R12 引入的新特性中有“Sub Binary”，大多数情况下，编译器会自动优化上述 <<_C:1/binary, Rest/binary>> 的语句，避免生成另一个 binary 。

R12还有什么新特性？令人期待啊。

Steve Vinoski 提出了一个 map reduce 的方案(代码见后面)，获得了比较好的效果。

Klacke (即Claes Wikstorm)指出：

Spawn cat 方法的缺陷在于缺乏控制。即，这可能导致大量消息发往 port 的所有者，造成大量来不及处理的消息堆积在 message queue 中(也就是 Ulf Wiger 提到的 input too fast 问题)。在 port 方法中，可以用 {line, L} 模式的 port 来改善这一问题，但仍然无法彻底解决缺乏控制的问题。

他认为，当前最佳“按行处理文件”的办法是：

1. 打开文件 file:open(Filename, [read, raw])
2. 在循环中用 buffer 获取文件内容 {ok, Bin} = file:read(Fd, BufSize),
3. 使用 binary 的正则表达式匹配库来处理，比如这个

他提到目前 otp 自带的 regex 包，当前的版本还有性能问题。

Steve Vinoski 指出：

虽然用并发改进了速度，但 Erlang 的文件 io 缓慢仍然是无法回避的问题。他进一步深化了讨论，提出了 Erlang 是否有办法/计划改进文件 io 性能这样的本质问题。

Ulf Wiger 指出：

在 Erlang 最初的设计中，文件 io 的设计原则是要尽可能的减少侵入。比如，mnesia的日志写入等，都被设计为低优先级的后台进程，少有需要读取大文件的应用场景。随着 Erlang 向其他的应用领域发展，文件 io 的要求越来越高，此时文件 io 的问题就被越来越多的人诟病。这个问题需要设计者们来加以改进。

Per Gustafsson 给出了目前为止最快的纯 Erlang 方案(代码见后面)。

Klacke 贡献了早在 Bluetail 时期对这一问题的终极解决方案——更好的文件 io 模块 bfile (代码见后面)，使用这一模块，可以获得与 C 相当的文件 io 性能，以及直接支持的分行处理。

【方案】

Steve Vinoski 想到了利用 Erlang 强大的并发能力来加速这个过程。他的代码是这样的：

他的主要思路是，读取文件，拆分成 Num 个部分进行“分行”处理，然后用“map reduce”来处理匹配。
运行时：

当他把 process 数量调到 4000 左右的时候，获得了比较稳定的速度。

Caoyuan 的另一个方案是这样的：

这个方案起了多个进程来并发读取文件，然后用 collect_loop 将各个片段转换为小的 lists ，scan_line 会进行分行处理，然后用 process_match 来匹配。这里的要点在于，lists的大小为 4096 比较合适。

Per Gustafsson 的方案是这样的：

以及

他的方法综合使用了上面提到的几种优化方法，用 buffer 读文件，每次迭代处理多个字节，并发处理耗时的 binary 转换。因而，获得了现有纯 Erlang 方法中最佳的性能。

Klacke 的 bfile 模块提供了和其他语言一样丰富的分行文件 io 特性。这个包是以 c – Erlang driver 的代码的方式提供的，可以从这里下载到这个包

用起来象这样：

【结论】
0. Erlang 目前的文件 io 模块确实糟糕，这个 io:read_line 用来处理 console 输入就好了，不要用来做大文件的读取。
1. 可以用 file:read 以二进制的方式来读取文件，但它不提供分行，所以，你最好自己来写个 buffer 读取。
2. 把一个 200M 的东西放到内存中，再搞 binary_to_list 的转换，这不是一个好主意。
3. 有了 list 就好办了，怎么弄都快了。
4. 上面的步骤中，如果发现某个步骤很慢，那么可以考虑用 map reduce 来加速。
5. 不要死脑筋，该用 port 就用 port （虽说有控制不力的问题，但可以用分行来缓解），该写 driver 就写 driver （毕竟 Erlang 是开源的，没什么妨碍你去扩展它），别费半天的功夫去和一个“设计缺陷”较劲。

[BLAH]
PS1. Bluetail 私藏的好东西可真多啊，Erlang 真是没人疼的好孩子。
PS2. Erlang 的社区是个好社区，不回避问题，有合作精神，乐于贡献。
PS3. 现在搞程序的都用 Mac Power Book ？好像没有 Mac Book 都不好意思和人打招呼。汗自己一个。

study