How the BEAM boots and what can be done about it

The Erlang VM does a lot of work loading and transforming many little BEAM files before it is ready to go. When starting Elixir even more beam files have to be loaded. Doing this work over and over again leads to unfavourable startup time. Most clearly this shows on embedded systems with weak CPUs, inefficient files systems and storage and no way to cache the filesystem when switched on. But this extra work also shows up everywhere the Erlang VM is started again and again, e.g. during development and in CI/CD systems. In this talk, we explore what exactly is done by the BEAM loader and how we can move this work to release build time so it doesn't have to be done again and again on startup. Transforming all the little BEAM files into normal object files a static or dynamic linker can use and relocate gives us several benefits at the same time: Ready to run in place beam code - reduced startup time.Faster cloud spin uptime with standard Erlang VMs Single executable releases - wouldn't it be nice to deploy just a single-file executable that contains the Erlang VM and the complete relates BEAM files? Deploy complete Erlang releases on System on Chip Micro-Controllers by running everything directly in firmware flash In this talk, you will get a clear explanation of how all this works and demos of the implementation.