Efficiency Guide

User's Guide

Version 9.3

- User's Guide
- PDF
- Top

- Expand All
- Contract All

### Chapters

- Introduction
  - Top of chapter
  - Purpose
  - Prerequisites
- The Seven Myths of Erlang Performance
  - Top of chapter
  - Myth: Tail-Recursive Functions are Much Faster Than Recursive Functions
  - Myth: Operator "++" is Always Bad
  - Myth: Strings are Slow
  - Myth: Repairing a Dets File is Very Slow
  - Myth: BEAM is a Stack-Based Byte-Code Virtual Machine (and Therefore Slow)
  - Myth: Use "_" to Speed Up Your Program When a Variable is Not Used
  - Myth: A NIF Always Speeds Up Your Program
- Common Caveats
  - Top of chapter
  - Timer Module
  - list_to_atom/1
  - length/1
  - setelement/3
  - size/1
  - split_binary/2
  - Operator "--"
- Constructing and Matching Binaries
  - Top of chapter
  - How Binaries are Implemented
  - Constructing Binaries
  - Matching Binaries
  - Historical Note
- List Handling
  - Top of chapter
  - Creating a List
  - List Comprehensions
  - Deep and Flat Lists
  - Recursive List Functions
- Functions
  - Top of chapter
  - Pattern Matching
  - Function Calls
  - Memory Usage in Recursion
- Tables and Databases
  - Top of chapter
  - Ets, Dets, and Mnesia
  - Ets-Specific
  - Mnesia-Specific
- Processes
  - Top of chapter
  - Creating an Erlang Process
  - Process Messages
  - SMP Emulator
- Drivers
  - Top of chapter
  - Drivers and Concurrency
  - Avoiding Copying Binaries When Calling a Driver
  - Returning Small Binaries from a Driver
  - Returning Large Binaries without Copying from a Driver
- Advanced
  - Top of chapter
  - Memory
  - System Limits
- Profiling
  - Top of chapter
  - Do Not Guess About Performance - Profile
  - Memory profiling
  - Large Systems
  - What to Look For
  - Tools
  - Benchmarking
- Retired Myths
  - Top of chapter
  - Myth: Funs are Slow
  - Myth: List Comprehensions are Slow

# 12 Retired Myths

We belive that the truth finally has caught with the following, retired myths.

### 12.1 Myth: Funs are Slow

Funs used to be 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.

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 apply/3.

### 12.2 Myth: List Comprehensions are Slow

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 myth that tail-recursive functions are faster than body-recursive functions.