User's Guide
PDF
Top

Efficiency Guide
User's Guide
Version 5.8

Expand All
Contract All

Chapters

• Introduction
  • Top of chapter
  • Purpose
  • Prerequisites
• The Eight Myths of Erlang Performance
  • Top of chapter
  • Myth: Funs are slow
  • Myth: List comprehensions are slow
  • Myth: Tail-recursive functions are MUCH faster than recursive functions
  • Myth: '++' 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
• Common Caveats
  • Top of chapter
  • The regexp module
  • The timer module
  • list_to_atom/1
  • length/1
  • setelement/3
  • size/1
  • split_binary/2
  • The '--' operator
• Constructing and matching binaries
  • Top of chapter
  • How binaries are implemented
  • Constructing binaries
  • Matching binaries
• List handling
  • Top of chapter
  • Creating a list
  • List comprehensions
  • Deep and flat lists
  • Why you should not worry about recursive lists 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
  • Creation of an Erlang process
  • Process messages
  • The SMP emulator
• Drivers
  • Top of chapter
  • Drivers and concurrency
  • Avoiding copying of binaries when calling a driver
  • Returning small binaries from a driver
  • Returning big binaries without copying from a driver
• Advanced
  • Top of chapter
  • Memory
  • System limits
• Profiling
  • Top of chapter
  • Do not guess about performance - profile
  • Big systems
  • What to look for
  • Tools
  • Benchmarking

1 Introduction

1.1  Purpose

Premature optimization is the root of all evil. -- D.E. Knuth

Efficient code can be well-structured and clean code, based on 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 should only contain the first kind of efficient code. If that turns out to be too slow, you should profile the application to find out where the performance bottlenecks are and optimize only the bottlenecks. Other code should stay as clean as possible.

Fortunately, compiler and run-time optimizations introduced in R12B makes it easier to write code that is both clean and efficient. For instance, the ugly workarounds needed in R11B and earlier releases to get the most speed out of binary pattern matching are no longer necessary. In fact, the ugly code is slower than the clean code (because the clean code has become faster, not because the uglier code has become slower).

This Efficiency Guide cannot really learn 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. We have generally not included general tips about optimization that will work in any language, such as moving common calculations out of loops.

1.2  Prerequisites

It is assumed that the reader is familiar with the Erlang programming language and concepts of OTP.