Everyone has an opinion about whether the BEAM is fast or slow. Almost nobody has actually measured it properly.
Tobias Pfeiffer -PragTob on the internet, benchmarking nerd, real-time engineer at Supabase -came to Elixir from Ruby because Ruby couldn't handle WebSockets at scale. Then he learned the language the way he learns every language: by building a benchmarking library. Ten years later, Benchee is what most of the Erlang and Elixir world reaches for when it wants a number instead of an argument.
why Tobias writes a benchmarking library every time he learns a new language -and what that discipline actually teaches about how a runtime works
the production scar: a benchmark that showed one query was faster, deployed it, and discovered the benchmark had been measuring the wrong input entirely
the single most important insight about benchmarking: most people quietly fool themselves and walk away more confident and more wrong than when they started
inputs as a first-class feature -the lesson José Valim taught Tobias within 17 minutes of an open GitHub issue
why body-recursive map is faster than tail-recursive map for small lists on the BEAM -and what that tells you about the runtime
what reductions are, why they're a more stable measurement than wall time, and when they diverge
how Benchee measures memory: spawning a monitored process, watching GC events, reporting exact bytes -and why deterministic code gives deterministic memory
the JSON benchmarking arms race -built-in OTP JSON, jason, Jiffy, and why comparison benchmarks usually miss the point
why Benchee has no macros, no DSL, and deliberately only uses functions -and why that design decision made it composable in ways nobody predicted
the hardest benchmarking mistake to stop making: confusing latency and throughput
what Toby wishes more Elixir developers understood about BEAM performance before they opened a PR claiming something was faster
Recorded August 21, 2026.
