erlang efficient guide 2

2 The Eight Myths of Erlang Performance

项目现在终于有点空闲时间了，看看erlang doc，觉得不错，就自己尝试看看，怕不是很理解就翻译出来。自己总结，感觉点很多，要成一个系统的去学习去不断的尝试才能理解这些原则和设计。慢慢去尝试吧。
注：【】内是我自己加的哦】

• Some truths seem to live on well beyond their best-before date, perhaps because "information" spreads more rapidly from person-to-person faster than a single release note that notes, for instance, that funs have become faster.

• 一些真相似乎已还是如同从前那么真，因为人人口头留传远比版本上说明快得多，（但不是口口相传并不能记录所有的改变），比如说：匿名函数fun变得更快。

Here we try to kill the old truths (or semi-truths) that have become myths.
现在我们来粉碎那一些已是神话（过时）的真理或半真理吧。
2.1 Myth: Funs are slow
2.1 funs非常慢【我认为：错60%对40%比MFA还是慢的多，在频繁调用里用MFA好】

• Yes, funs used to be slow. Very slow. Slower than apply/3. Originally, funs were implemented using nothing more than compiler trickery, ordinary tuples, apply/3, and a great deal of ingenuity.

• 是的，以前funs是慢，非常慢，比apply/3还慢，是因为最开始时，funs只要为了通过编译（我的理解设计来让编译器不报错，好解释一点），通过最原始的元组，apply/3,和其它的一些新东西来实现的。【由apply/3来实现，固然比apply/3慢一点啦】。

• But that is ancient history. Funs was given its own data type in the R6B release and was further optimized in the R7B release. Now the cost for a fun call falls roughly between the cost for a call to local function and apply/3.

• 但是那已是非常久远的历史了，funs在R6B release(注意不是R16B...)已是一种数据结构了，同时在R7B也做了一些优化，现在fun 的消耗在本地调用和apply/3之间
• 附：目前比较准确的消耗统计：

2.2 Myth: List comprehensions are slow
2.2 列表解析很慢【错】

• List comprehensions used to be implemented using funs, and in the bad old days funs were really slow.

• 列表解析以前用funs实现的，所以在那funs慢的时代自然也很慢啦。

• Nowadays the compiler rewrites list comprehensions into an ordinary recursive function. Of course, using a tail-recursive function with a reverse at the end would be still faster. Or would it? That leads us to the next myth.

• 现如今，编译器用递归重写了列表解析，当然用一个尾递归和一个lists:reverse来实现依然是非常快的。直的嘛，让我们来看看下一个神话。【所以不要用lists:foldr/3而是用lists:foldl/3+reverse/1来做好的多】

2.3 Myth: Tail-recursive functions are MUCH faster than recursive functions
2.3 尾递归比递归快得多【错50%对50%】

• According to the myth, recursive functions leave references to dead terms on the stack and the garbage collector will have to copy all those dead terms, while tail-recursive functions immediately discard those terms.

• 根据尾递归比递归快得多的神话，递归函数把不需要的terms留在栈中并让垃圾回收器来copy这些不需要的数据，而尾递归则是直接把不需要的terms丢弃

• That used to be true before R7B. In R7B, the compiler started to generate code that overwrites references to terms that will never be used with an empty list, so that the garbage collector would not keep dead values any longer than necessary.

• 这在R7B运行是这样的，在R7B，编译器开始用一个空列表来覆盖那些不需要的terms并用这空间来写代码，所以垃圾回收不用再保存那些不必要的值了。

• Even after that optimization, a tail-recursive function would still most of the time be faster than a body-recursive function. Why?

• 那么经过这些优化，一个尾递归是不是还是比一个body-recursive function快一点呢？

• It has to do with how many words of stack that are used in each recursive call. In most cases, a recursive function would use more words on the stack for each recursion than the number of words a tail-recursive would allocate on the heap. Since more memory is used, the garbage collector will be invoked more frequently, and it will have more work traversing the stack.

• 这要看有多少栈空间被用于递归，在大多数情况下，一个递归在栈上使用的空间会比尾递归分在堆上的空间多的多，空间多，自然会触发垃圾回收器更加频繁地遍历这些栈。

• In R12B and later releases, there is an optimization that will in many cases reduces the number of words used on the stack in body-recursive calls, so that a body-recursive list function and tail-recursive function that calls lists:reverse/1 at the end will use exactly the same amount of memory. lists:map/2, lists:filter/2, list comprehensions, and many other recursive functions now use the same amount of space as their tail-recursive equivalents.

• 在R12B及以后的版本中，还有一个优化：使用一个body-recursive 的空间消耗和使用尾递归+lists:reverse/1一样的。list:map/2,lists:filter/3.列表解析及其它的recursive function使用的空间和尾递归是几乎相同的。

So which is faster?
那么。那一个更快？

• It depends. On Solaris/Sparc, the body-recursive function seems to be slightly faster, even for lists with very many elements. On the x86 architecture, tail-recursion was up to about 30 percent faster.

• 这要看情况：在Solaris/Sparc，body-recursive 函数似乎快一点，即使对于一个是非常长的list，在x86结构里,尾递归比body-recursive快30%。

• So the choice is now mostly a matter of taste. If you really do need the utmost speed, you must measure. You can no longer be absolutely sure that the tail-recursive list function will be the fastest in all circumstances.

• 所以现在选择使用那一个，完全是一种个人喜好，如果你真的非常在意速度，你必须要权衡一下，现在请不要相信尾递归在所有的环境下是最快了。

• Note: A tail-recursive function that does not need to reverse the list at the end is, of course, faster than a body-recursive function, as are tail-recursive functions that do not construct any terms at all (for instance, a function that sums all integers in a list).

• Note:一个不需要反转的尾递归绝对比body-recursive function快的！因为尾递归真的是不产生任何多余的数据项，（以上说的消耗来自于lists:reverse/1）

2.4 Myth: '++' is always bad
2.5 "++"总是非常坏的一种选择【错50%对50%】

• The ++ operator has, somewhat undeservedly, got a very bad reputation. It probably has something to do with code like

• ”++“ 一直有一个非常不好的声誉，可能原因：你的用法不正确，比如：

DO NOT

naive_reverse([H|T]) ->
    naive_reverse(T)++[H];
naive_reverse([]) ->
    [].

• which is the most inefficient way there is to reverse a list. Since the ++ operator copies its left operand, the result will be copied again and again and again... leading to quadratic complexity.

• 这是最没效率去反转一个list，”++“会复制左边的元素，这个会使复制多次，导致平方倍的复杂度。

On the other hand, using ++ like this
但是另一方面：下面这种用法就好了：
OK

naive_but_ok_reverse([H|T], Acc) ->
    naive_but_ok_reverse(T, [H]++Acc);
naive_but_ok_reverse([], Acc) ->
    Acc.

• is not bad. Each list element will only be copied once. The growing result Acc is the right operand for the ++ operator, and it will not be copied.

• 这并不是一个是非常坏的尝试，每个列表元素只被copy一次，那增长的Acc是在++的右边的，他不会每次都被copy的

Of course, experienced Erlang programmers would actually write
当然，最佳实践还是下面这种：
DO

vanilla_reverse([H|T], Acc) ->
    vanilla_reverse(T, [H|Acc]);
vanilla_reverse([], Acc) ->
    Acc.

• which is slightly more efficient because you don't build a list element only to directly copy it. (Or it would be more efficient if the the compiler did not automatically rewrite [H]++Acc to [H|Acc].)

• 这比上面的还要高效一点点，你根本不用去建造一个list元素，直接copy他就可以了（或者：如果编译器不把[H]++Acc重写为[H|Acc] ，那就更高效啦）。

2.5 Myth: Strings are slow
2.5 字符串很慢【对70%错30%，如果你选择错了，那就会非常痛苦】

• Actually, string handling could be slow if done improperly. In Erlang, you'll have to think a little more about how the strings are used and choose an appropriate representation and use the re module instead of the obsolete regexp module if you are going to use regular expressions.

实际上：字符串处理不适当会显得很慢，在erlang，你不得不思考一下如何使字符串是怎样使用的，并选择适当的显示方式，如果要用正则就用re module来处理。

2.6 Myth: Repairing a Dets file is very slow
2.6 修复一个dets文件是非常慢【对90%】

• The repair time is still proportional to the number of records in the file, but Dets repairs used to be much, much slower in the past. Dets has been massively rewritten and improved.

• 修复仍然取决于文件中reocord的数量，但是比dets重写后比以前快多了。

2.7 Myth: BEAM is a stack-based byte-code virtual machine (and therefore slow)
2.7  Beam文件是一个基于堆栈的字节虚拟机（所以很慢）【错100%】

• BEAM is a register-based virtual machine. It has 1024 virtual registers that are used for holding temporary values and for passing arguments when calling functions. Variables that need to survive a function call are saved to the stack.

• BEAM 是一个基于寄存器的虚拟机，它有1024的虚拟寄存器来保存临时变量和使用函数。在函数调用后存放的变量放在栈中。

• BEAM is a threaded-code interpreter. Each instruction is word pointing directly to executable C-code, making instruction dispatching very fast.

• BEAM 是一个threaded-code 翻译器，每一个指令都指向对应的c代码，这使得它的调试快的一B。

2.8 Myth: Use '_' to speed up your program when a variable is not used
2.8 在一个不使用的变量时使用 "_"来加速效率【错】

• That was once true, but since R6B the BEAM compiler is quite capable of seeing itself that a variable is not used.

• 这以前是真的，但是自从R6B【为什么讲的都是那么老的版本，感觉这文档是不是过时了呀】，编译器可以自己判断变量是不是没有使用，而做相应的优化。

新一代的影帝！！！