This document discusses various ways to improve memory and performance efficiency in Erlang programs. It covers the memory usage and performance characteristics of common Erlang data types like literals, immediates, boxed values, lists, tuples, binaries, ETS, and functions. Some key points include: literals and immediates have very low memory overhead; lists have efficient prepend but inefficient append; tuples have good locality but copying is expensive; binaries have reference counting for large values; ETS implies data copying; and external term format is CPU intensive for encoding. The document provides advice on optimizing for these behaviors.

1. Efficient Erlang
Performance and memory efficiency of your data

2. About me and this talk
7 years of Erlang
20 years of C and C++
3 years experience with BEAM VM source and writing my own implementations
Github, twitter: kvakvs

3. Literal Values
● Literals are values mentioned in the module code
○ Loaded with module, stored in a separate const heap
○ Cheap to access
○ Literal tuples make fast lookup tables
● Size in process heap 1W until module reload, then copied by the GC
○ Each reload potentially creates a copy

4. Immediates
● Fit into a machine word
○ Small integers
○ Local pids and ports
○ Atoms
○ NIL [ ] and invisible special values (the non-value)
Size is always 1W

5. Immediates+
● Cheap and fast
● 2 bits are reserved to indicate immediate value
● 2-4 bits more are used to determine the type
○ Hence why small integer can only be 28/60 bits long
Size is always 1W

6. Immediate: Numbers
● Small integers: 28 or 60 bits
○ Caveat Convert to big automatically! (3+ words), watch your counters!
● Floats are NOT immediate, an 8-byte IEEE double stored on heap
○ Expensive and inefficient
○ Consider: Fixed point or N÷M fraction
Smallint size is 1W
Float size is 1+(2 or 3) W

7. Immediate: Atoms
● No GC for atoms
● Comparing two atoms
○ Equality is O(1)
○ Comparing to another type is O(1)
○ Order comparisons are O(N)
● Inefficient in external term format
Size is always 1W
+String in the atom tab (once)

8. SIZE, TYPE
Boxed Values
● A pointer to some object on heap
● Always at least 1 header word is
used (lists have no header)
● Can point to:
○ Lists (cons) cells, tuples, maps
○ Remote pids, remote refs
○ Float numbers and bignums
○ Binary fragments or heap binaries
A box pointer is always 1W
Size of a boxed value varies
<<”Hello”>>

9. Lists: Memory
● A list element is a cell of 2 terms
○ Stores 1 value and a tail — [1 | [2 | []]]
○ Improper lists can store 2 values in 1 cell — [1 | 2]
Box pointer is 1W
Size on heap is 2W
1 [2|[]]
2 NIL []1 2
[1|2]
[1,2]

10. Lists: Performance
● A list can only be traversed forward
● N-th element O(N), prepend O(1), append O(N)
○ Can express via IOList at O(1) — [L1, L2]
● – – operation is O(N*M), use ordsets or gb_sets for
the right arg
○ It is not too bad if the right argument is short
● ++ operation is O(N) because: finding last element
● lists:flatten, lists:reverse build a new list
1 [2|[]]
2 NIL []
[1,2]

11. List tricks
● Store another value instead of a trailing NIL
○ Improper list
○ [X | Y] takes 1+2 words
which is smaller, than [X, Y | []] — 1+4 words,
also smaller, than {X, Y} — 1+3 words
● Reversing is (relatively) cheap
● Reusing any tail of any list cell is cheap
● The compiler can optimize a LC if the result is not used

12. ● Cells have potentially random locations
● Cheap to build
● When you build a list in a loop, cells will be contiguous
● Will potentially preserve contiguity after GC
Lists: Memory Locality

13. IO Lists
● Allows to join different types of string data at O(1)
● Accepted by most IO functions
● Have little memory overhead (some list cells at 2W each)
● Fast, memory efficient
○ Similar to: Rope (data structure)
● Do more IO lists, it is good for you
Image courtesy of Wikipedia/Rope

14. Tuples
● A tuple is an immutable array of Terms
● Prefixed by length (26 bit limit)
Box pointer is 1W
Size on heap is 1+arity
3 1
{1,a,b}
‘a’ ‘b’

15. Tuples: Another example
Box pointer is 1W
Size on heap is 1+arity
2 ‘error’
{error,{undef,start}}
{undef,start}
2 ‘undef’ ‘start’
Memory locality can be
poor unless created at
the same time

16. Tuples: Copying
● Modification = making a copy
○ Not copied: descending literal integer indices are modified without other calls in between
● Avoid copying: Store mutable fields at the top level of your records
● Copying nested unchanged structures is cheap
Box pointer is 1W
Size on heap is 1+arity

17. ● Tuples are really fast to build and read
● Tuples are slow to modify O(N)
○ Also a full tuple copy most often is performed
● Consider converting to a list temporarily
● Memory locality — tuples are contiguous arrays
● GC will attempt to group tuple members in memory
Tuples: Performance

18. Maps
● Represented differently with breaking point at 32 elements
○ [<32] Compact key/value array
○ [>32] HAMT (Hash array mapped trie)
● Slower than records for obvious reasons
● Updating a large map would rebuild only path to the modified pair
● Using maps to store state: easy to add keys

19. Data is copied, when it
● leaves the process as a message to
another process or port
● is used as args when spawning
● is stored/retrieved from ETS
Exception:
● Large binaries > 64 bytes
Process Value
ETS Ports
Other
Processes
Binary
Heap Value

20. Binaries
A simple heap binary example
32-bit word size
2, binary 5 H
<<”Hello”>>
e l l o

21. Binary Heap
Process
Binaries
● Boxed values, exist on the process or the
binary heap
● A large binary is made of:
○ a refc bin on the binary heap
○ a proc bin which points to a refc bin
● A heap bin is a local small binary with a 2
word header and < 64b data
● A sub binary and match context are two
special cases
refc bin
proc bin
Process
sub bin
heap bin
proc bin

22. Binaries: The good news
● Chain of binary append operations will be optimized if there
was ONLY ONE use of that binary throughout the operation.
● Unused variables in a binary match can be optimized away
○ Unused part of binary in all fun clauses:
f(<<_,X/binary>>) -> …
● How to see binary optimizations:
○ erlc +bin_opt_info zzz.erl
○ export ERL_COMPILER_OPTIONS=bin_opt_info

23. Binaries: Please avoid
● Exposing large bin to multiple processes increases refcount and
holds the binary alive until the GC runs on all these processes!
● Pay attention when growing a binary — it will copy:
○ When the binary is sent as a message in the middle of manipulation
○ When the binary is inserted into ETS, sent to a port or to a NIF
○ When matching a binary (match context creates a pointer to the binary data)
● binary:match can produce lots of matches/sub binaries

24. ETS: Performance
● Storing/retrieving data implies copying
● Reading/modifying large terms is expensive
○ Consider having a second table with the mutable field
● Atoms are efficient in ETS but not in DETS

25. External Term Format (term_to_binary)
● Used over the network or to store terms on disk (database)
● Atoms: encoded as strings
○ Network, DETS/Mnesia, binary blobs in database
● Encoding large terms is CPU intensive

26. Functions
● Local function calls are fast
○ External function calls are slower (x3)
○ Apply calls are the slowest (x6)
● Lambdas are local function pointers (M:F/Arity)
○ List, binary comprehensions, QLC are lambdas
○ Lambdas are normal functions, but
○ Extra invisible args are added sometimes
○ Binary references may be held forever

27. Fin
Thanks for watching