首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

2. The Seven Myths of Erlang Performance

有些事实看起来生活在远远超出自己最佳的日期之前,也许是因为“信息”在人与人之间传播速度比单个版本说明更快,例如,说主体递归调用变得更快。

这部分试图销毁已成为myths的旧真理(或半真理)。

2.1 Myth:尾递归函数比递归函数快得多

根据这个myth,使用一个尾递归函数来构建一个反向列表,然后调用lists:reverse/1它比一个按照正确顺序构建列表的body-recursive函数更快; 原因在于主体递归函数比尾递归函数使用更多的内存。

在R12B之前,这在某种程度上是事实。在R7B之前更是如此。今天,不是那么多。主体递归函数通常使用与尾递归函数相同数量的内存。通常不可能预测尾递归或身体递归版本是否会更快。因此,使用让代码更清晰的提示(提示:通常是body-recursive版本)。

有关尾部和主体递归的更全面的讨论,请参阅Erlang's Tail Recursion is Not a Silver Bullet

尾部递归函数不需要在末尾逆序列表比尾部递归函数要快,而尾部递归函数也不会构造任何项(比如,一个将所有整数求和的函数一个列表)。

2.2 Myth:运算符“++”总是不好

++操作符,有些不应存在。这可能与代码如下所示有关,这是扭转列表效率最低的方式:

DO NOT

代码语言:javascript
复制
naive_reverse([H|T]) ->
    naive_reverse(T)++[H];
naive_reverse([]) ->
    [].

++操作员复制其左操作数时,结果会被重复复制,从而导致二次复杂性。

但使用++如下所示并不坏:

OK

代码语言:javascript
复制
naive_but_ok_reverse([H|T], Acc) ->
    naive_but_ok_reverse(T, [H]++Acc);
naive_but_ok_reverse([], Acc) ->
    Acc.

每个列表元素只被复制一次。不断增长的结果Acc是对正确的操作++操作符,并且它被复制。

有经验的Erlang程序员会这样写:

DO

代码语言:javascript
复制
vanilla_reverse([H|T], Acc) ->
    vanilla_reverse(T, [H|Acc]);
vanilla_reverse([], Acc) ->
    Acc.

这样稍微高效一些,因为在这里你不会构建一个列表元素直接复制它。(或者,如果编译器不会自动重写[H]++Acc,效率会更高[H|Acc]。)

2.3 Myth:字符串处理慢

如果处理不当,字符串处理速度会变慢。在Erlang中,您需要更多地考虑如何使用字符串并选择适当的表示形式。如果使用正则表达式,请re在STDLIB中使用模块,而不要使用过时的regexp模块。

2.4 Myth:修复一个Dets文件非常慢

修复时间仍然与文件中记录的数量成正比,但过去修理过去要慢得多。Dets已被大量改写和改进。

2.5 Myth:BEAM是一个基于堆栈的字节码虚拟机(因此速度较慢)

BEAM是基于注册表的虚拟机。它有1024个虚拟寄存器,用于保存临时值和调用函数时传递参数。需要在函数调用期间生存的变量保存到堆栈。

BEAM是一个线程代码解释器。每条指令都是直接指向可执行C代码的指令,使得指令调度非常快速。

2.6 Myth:当不使用变量时,使用“_”加快程序速度

那曾经是真的,但是从R6B BEAM编译器可以看到一个变量没有被使用。

同样,源代码级别上的微不足道的转换(例如将case函数顶层的语句转换为子句很少会对生成的代码产生影响)。

2.7 Myth:NIF总是加快你的计划

将Erlang代码重写到NIF以使其更快应该被看作是最后的手段。它只保证是危险的,但不能保证加快程序。

每个NIF电话会做太多的工作degrade responsiveness of the VM。做得太少的工作可能意味着NIF中更快处理的获益被调用NIF和检查参数的开销所吞噬。

请务必在编写NIF之前阅读Long-running NIFs

扫码关注腾讯云开发者

领取腾讯云代金券