Some truths seem to live on well beyond their best-before date, perhaps because "information" spreads faster from person-to-person than a single release note that says, for example, that funs have become faster.
This section tries to kill the old truths (or semi-truths) that have become myths.
Funs used to be very slow, slower than
But that is history. Funs was given its own data type
in R6B and was further optimized in R7B.
Now the cost for a fun call falls roughly between the cost for a call
to a local function and
List comprehensions used to be implemented using funs, and in the old days funs were indeed slow.
Nowadays, the compiler rewrites list comprehensions into an ordinary recursive function. 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.
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.
Even after that optimization, a tail-recursive function is still most of the times faster than a body-recursive function. Why?
It has to do with how many words of stack that are used in each recursive call. In most cases, a recursive function uses more words on the stack for each recursion than the number of words a tail-recursive would allocate on the heap. As more memory is used, the garbage collector is invoked more frequently, and it has more work traversing the stack.
In R12B and later releases, there is an optimization that
in many cases reduces the number of words used on the stack in
body-recursive calls. A body-recursive list function and a
tail-recursive function that calls
So, which is faster? It depends. On Solaris/Sparc, the body-recursive function seems to be slightly faster, even for lists with a lot of elements. On the x86 architecture, tail-recursion was up to about 30% faster.
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 sure that the tail-recursive list function always is the fastest.
A tail-recursive function that does not need to reverse the list at the end is faster than a body-recursive function, as are tail-recursive functions that do not construct any terms at all (for example, a function that sums all integers in a list).
The
DO NOT
naive_reverse([H|T]) ->
naive_reverse(T)++[H];
naive_reverse([]) ->
[].
As the
But using
OK
naive_but_ok_reverse([H|T], Acc) ->
naive_but_ok_reverse(T, [H]++Acc);
naive_but_ok_reverse([], Acc) ->
Acc.
Each list element is copied only once.
The growing result
Experienced Erlang programmers would write as follows:
DO
vanilla_reverse([H|T], Acc) ->
vanilla_reverse(T, [H|Acc]);
vanilla_reverse([], Acc) ->
Acc.
This is slightly more efficient because here you do not build a
list element only to copy it directly. (Or it would be more efficient
if the compiler did not automatically rewrite
String handling can be slow if done improperly.
In Erlang, you need to think a little more about how the strings
are used and choose an appropriate representation. If you
use regular expressions, use the
The repair time is still proportional to the number of records in the file, but Dets repairs used to be much slower in the past. Dets has been massively rewritten and improved.
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 is a threaded-code interpreter. Each instruction is word pointing directly to executable C-code, making instruction dispatching very fast.
That was once true, but from R6B the BEAM compiler can see that a variable is not used.