File: bif.html

package info (click to toggle)
erlang-doc-html 1%3A11.b.2-1
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k
  • size: 23,284 kB
  • ctags: 10,724
  • sloc: erlang: 505; ansic: 323; makefile: 62; perl: 61; sh: 45
file content (100 lines) | stat: -rw-r--r-- 2,526 bytes parent folder | download
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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
  <TITLE>Built in functions</TITLE>
  <SCRIPT type="text/javascript" src="../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
      ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="6"><!-- Empty --></A>
<H2>6 Built in functions</H2>
<A NAME="6.1"><!-- Empty --></A>
<H3>6.1 Some notes about BIFs</H3>

<P>     
<P>
<DL>

<DT>
<STRONG>list_to_atom/1</STRONG>
</DT>

<DD>
Since atoms are not garbage collected it is not a good
        idea to create atoms dynamically in a system that will run
        continously. Sooner or later the limit 1048576 for number of
        atoms will be reached with a emulator crash as result. In
        addition to the bad memory consumption characteristics the
        function is also quite expensive to execute. 
</DD>

<DT>
<STRONG>length/1</STRONG>
</DT>

<DD>
is an operation on lists and each time the
        length is tested the entire list must be traversed. Since
        length is implemented in C it is quite efficient anyway but it
        still has linear characteristics. The size/1 function which
        can be applied on tuples and binaries is for example much more
        efficient since it only reads a size field in the internal
        data structure. 
</DD>

<DT>
<STRONG>setelement/3</STRONG>
</DT>

<DD>
Compared with element/2 that is very efficient and independent of the tuple size
        setelement/3 is an expensive operation for large tuples 
        (&#62;50 elements) since it implies that all fields must be copied 
        to a new tuple. Therefore it is not recommended to use setelement in recursions 
        involving large tuples.
        
</DD>

<DT>
<STRONG>split_binary/2</STRONG>
</DT>

<DD>
Depending on the situation it is in most cases more 
        efficient to split a binary through matching instead of calling
        the split_binary/2 function.<BR>

        <STRONG>DO</STRONG><BR>

        
<PRE>
        &#60;&#60;Bin1:Num/binary,Bin2/binary&#62;&#62; = Bin,
        
</PRE>

        <STRONG>DON'T</STRONG><BR>

        
<PRE>
        {Bin1,Bin2} = split_binary(Bin,Num),
        
</PRE>

        
</DD>

</DL>
<CENTER>
<HR>
<SMALL>
Copyright &copy; 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>