1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<chapter>
<header>
<copyright>
<year>2016</year>
<year>2017</year>
<holder>Ericsson AB, All Rights Reserved</holder>
</copyright>
<legalnotice>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
The Initial Developer of the Original Code is Ericsson AB.
</legalnotice>
<title>Retired Myths</title>
<prepared>Bjorn Gustavsson</prepared>
<docno></docno>
<date>2016-06-07</date>
<rev></rev>
<file>retired_myths.xml</file>
</header>
<p>We belive that the truth finally has caught with the following,
retired myths.</p>
<section>
<marker id="retired_myths"/>
<title>Myth: Funs are Slow</title>
<p>Funs used to be very slow, slower than <c>apply/3</c>.
Originally, funs were implemented using nothing more than
compiler trickery, ordinary tuples, <c>apply/3</c>, and a great
deal of ingenuity.</p>
<p>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 <c>apply/3</c>.</p>
</section>
<section>
<title>Myth: List Comprehensions are Slow</title>
<p>List comprehensions used to be implemented using funs, and in the
old days funs were indeed slow.</p>
<p>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 myth that tail-recursive functions are faster
than body-recursive functions.</p>
</section>
<section>
<title>Myth: List subtraction ("--" operator) is slow</title>
<p>List subtraction used to have a run-time complexity proportional to the
product of the length of its operands, so it was extremely slow when both
lists were long.</p>
<p>As of OTP 22 the run-time complexity is "n log n" and the operation will
complete quickly even when both lists are very long. In fact, it is
faster and uses less memory than the commonly used workaround to convert
both lists to ordered sets before subtracting them with
<c>ordsets:subtract/2</c>.</p>
</section>
</chapter>
|
