Erlang -- Introduction

Efficiency Guide

User's Guide

Version 10.6

- 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
- 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
  - Myth: List subtraction ("--" operator) is slow

# 1 Introduction

### 1.1 Purpose

"Premature optimization is the root of all evil" (D.E. Knuth)

Efficient code can be well-structured and clean, based on a sound overall architecture and sound algorithms. Efficient code can be highly implementation-code that bypasses documented interfaces and takes advantage of obscure quirks in the current implementation.

Ideally, your code only contains the first type of efficient code. If that turns out to be too slow, profile the application to find out where the performance bottlenecks are and optimize only the bottlenecks. Let other code stay as clean as possible.

This Efficiency Guide cannot really teach you how to write efficient code. It can give you a few pointers about what to avoid and what to use, and some understanding of how certain language features are implemented. This guide does not include general tips about optimization that works in any language, such as moving common calculations out of loops.

### 1.2 Prerequisites

It is assumed that you are familiar with the Erlang programming language and the OTP concepts.