Benjamin Philip

Elixir and FP Enthusiast, Linux user, Highschooler

Benjamin is an Elixir and Functional Programming enthusiast, and the maintainer of Erlang's Apache Arrow implementation. Though not a core contributor, he also frequently contributes to the Nx and Livebook projects with the occasional contributions to Hexpm and Hex. Being a 16-year-old high schooler, he does not have any professional programming experience but he tries to contribute to Opensource whenever time permits.

In his free time, he likes to read Non-Fiction and Fantasy, listen to 70s and 80s music (and additionally grumble about how nobody at school shares his taste in music) and crack terrible jokes. Beware. He's a bit of a Linux and Emacs zealot.

Optimizing Sequential Erlang

OBJECTIVES

This talk aims to provide a process to incrementally:
- Identify performance blocks in a codebase
- Find optimizations to address the blocks
- Balance different performance requirements (i.e. speed, memory usage etc.)
- Test which optimizations are effective in the long run

Expect to also learn how to pragmatically apply theoretical concepts like:
- Orders of Growth & Runtime Analysis
- Data Structures
- Algorithms
to aid you in identifying blocks and optimizations.

We will also briefly touch on when to optimize within Erlang, and when NIFs are more appropriate.

AUDIENCE

This talk is aimed at Erlang developers who would like to work on codebases which execute higher computational workloads in pure Erlang. While the principles of this talk can be applied to other BEAM languages such as Elixir, the actual tools and packages employed can vary.

DESCRIPTION

While implementing Apache Arrow for Erlang recently, I found handling the intensive parts in native code slow, so I wrote it in pure Erlang. It had to be performant because it would support Erlang's Telemetry implementation - vital to any BEAM web app.

With my initial code too slow, I had to learn a black art: optimizing sequential Erlang.

But it was easy to find optimizations to make, even easier to over-optimize, and painfully easy to optimize the wrong thing completely. I realized that I had 2 aspects to learn:

First, making a single optimization: How do I choose the right knob to turn? By how much? Did I get the results I expected? Is it maintainable?

Second, optimizing the system as a whole: Which bottlenecks to focus on and by how much? How do I stay pragmatic?

Let me share what I learned:
- The processes of performance optimization.
- Applying CS theory to design optimizations.
- The specifics of profiling, optimizing and hypothesizing for the BEAM

←Back